I’ve been getting my hands on v12 more and more. I like the improvements made to a lot of (tiny things) 
.
I am noticing though: I am less enthusiastic about the way the licensing is implemented currently. I think especially about the number of instances. I feel this was missed in earlier communication (or I just missed it).
It’s more technical. A common flow for me is to dump a database and restore it (like from staging to dev or production to dev). I have a feeling this will bite with a possible instance count. Obviously I will not deactivate a license before I would do that. So what would happen once I restore a dump locally and boot up Directus?
Additionally, on my local environment I sometimes adapt environment settings (like PUBLIC_URL) from production but other times I don’t. Some local environments might also have a license key loaded, some won’t.
And as an extra thought: how would that even work on the same environment? Like restoring a backup of production?
I’d rather ask and know this upfront because I am not willing to be caught off guard and suddenly unable to continue my work because of limits exceeded or other funky behavior 
.
This feeling also scares me because that is not how I used to feel about my projects using Directus. This part just feels different. I am not so sure yet 
.
Hi Jogchum, Glad to hear you're noticing all the small improvements in V12 - and completely fair to ask about this upfront. To clarify the baseline: the OIG grant gives you 5 license activations. Each activation is a binding of your project identifier (derived from the database) and your configured PUBLIC_URL. In a horizontal scaling or replica scenario, a shared db + shared PUBLIC_URL counts as one binding regardless of container count.
– James_WhiteOn your specific scenarios - Restoring a dump to the same environment: The token travels with the dump, so on boot Directus re-validates rather than re-activates. No new slot is consumed. Restoring a dump to a different environment (e.g. prod → local) This depends on your PUBLIC_URL: If your local PUBLIC_URL matches the source environment's - the refresh ping matches the existing binding and the token keeps renewing. No new activation is consumed. Worth noting: things like SSO may misbehave because the PUBLIC_URL is technically wrong for that environment.
– James_WhiteIf your local PUBLIC_URL differs - The instance won't drop immediately, but the refresh will eventually be rejected. The cleanest path for local restores is to dedicate one of your 5 activations to a local environment with a consistent PUBLIC_URL - and always use that same URL when restoring from any upstream environment. If 5 slots isn't enough to cover your setup (e.g. multiple developers each needing a local restore environment), we can increase your OIG limit.
– James_WhiteThanks for your response James, much appreciated! The technical clarification helps. Knowing that the binding is tied to the database identifier and PUBLIC_URL combination makes it more manageable. For now I can see that working for me.
– jogchumI do have a remaining thought about the instance limit though. I hope my intent is received well, I am not trying to be rude
. It’s because I think the instance limit is not correct combined with the OIG. Additionally it’s not great to not have some self-service tools for the licenses outside an instance itself. That might be on the roadmap but is not available today.
– jogchum