Thanks for the detailed questions, these are exactly the kinds of architectural considerations that matter for long-term enterprise adoption. I’ll address each one based on how Directus licensing and deployment work in practice.
1. PUBLIC_URL Activations
The 5 PUBLIC_URL activations you’re referring to are part of the Open Innovation Grant (the free self-hosted tier for organizations under 50 employees and <$5M in finances), not the Team plan.
For the Team plan: 1 license = 1 activation by default. If you need both staging and production environments, that would require purchasing 2 Team licenses.
However, one of the benefits of speaking directly with the Directus team is that we can discount non-production licenses — something we don’t offer as part of the self-serve motion on Team. If you’re running multiple environments (dev, staging, prod), it’s worth having a conversation to structure licensing in a way that makes sense for your deployment architecture.
For the Open Innovation Grant, those 5 activations are indeed meant to cover different environments of the same project (local, dev, test, staging, production) — not five independent installations.
2. Collection Counting
This is the most nuanced part of Directus licensing, and you’re right to dig into it.
What counts:
-
Business/domain collections you create
-
Translation collections (e.g., articles_translations)
-
Junction tables for M:N relationships
What typically does NOT count:
- System collections (the built-in Directus tables like
directus_users, directus_files, etc.)
In your example: 40 business collections + 60 translation collections + 50 junction tables — all 150 would count toward the Team plan limit. This is a common pain point for larger projects, especially multilingual or highly relational ones.
The count is based on what exists in your database schema that Directus manages, not just what’s visible in the Data Model UI. Automatically generated collections (translations, junctions) are still collections from a licensing perspective.
For a project with ~180 non-system collections, you’d probably need an Enterprise plan. The Team plan’s collection limit is designed for small-to-midsize projects; enterprise-scale data models quickly exceed it.
3. Flow Limits
The 20 Flow limit on Team is technically enforced. When you hit the limit, you can’t create Flow #21 without upgrading.
What happens:
-
The UI will prevent you from creating additional Flows
-
Existing Flows continue to work normally
-
Upgrading to Enterprise is a licensing change only, no migration, no reconfiguration, no downtime
You don’t need to re-architect or rebuild anything. The upgrade unlocks the limit; your project continues as-is.
4. Development by Software Companies
This is a common scenario for agencies and software companies building on behalf of clients.
Recommended approach:
Development/testing environments: If your company has <50 employees and <$5M in annual finances (revenue, funding, grants, etc.), you can self-host Directus for free under the MSCL license, no Team or Enterprise license required for non-production use.
Production environments: The customer needs a Team or Enterprise license for their production instance, based on their own financials and the project’s scale (collections, Flows, etc.).
Maintenance: If you’re maintaining the production instance on behalf of the customer, the license stays with the customer’s production environment.
If your company exceeds the MSCL threshold (≥50 employees or ≥$5M finances), you’d need a license even for self-hosted dev/test environments. In that case, you could leverage a Core plan for those. Otherwise, when issuing a Commercial License we would factor in how many environments you would need to activate the license key on — and as mentioned above, we can discount non-prod licenses when you work directly with our team.
5. Team → Enterprise Migration
Upgrading from Team to Enterprise is purely a licensing change. No migration, no reconfiguration, no architectural changes required.
You’re just unlocking limits (collections, Flows, users, etc.) and gaining access to Enterprise features (SSO, advanced RBAC, SLAs, etc.). The upgrade is seamless.
6. Real-World Collection Counts
You’re not alone — 180 collections is not unusual for enterprise projects, especially when you factor in:
-
Multilingual content (translation tables)
-
Complex relational models (junction tables)
-
Modular or multi-tenant architectures
The Team plan is designed for small-to-midsize projects (think: 10–50 business collections, limited translations/junctions). Once you’re building at enterprise scale, especially with rich relational data or multilingual content, Enterprise would be the right fit.
The collection limit isn’t arbitrary; it’s a proxy for project complexity and scale. A 180-collection project is enterprise-grade by definition, and the Enterprise plan gives you the support, SLAs, and infrastructure guarantees that match that scale.
Bottom Line
For your use case (enterprise projects with 180+ collections, multilingual content, and complex relationships) you’re in Enterprise territory. The Team plan works well for smaller projects, but the collection and Flow limits are designed to segment by project scale, not artificially restrict usage.
Next steps:
If you’re evaluating for a specific project, I’d recommend reaching out to Directus’ sales team to discuss Enterprise pricing and deployment options (self-hosted vs. Cloud). We can offer custom pricing based on your use case, including discounted non-prod licenses.
If you’re an agency/software company, clarify your own MSCL eligibility for internal dev environments, that can save significant cost.
Happy to dig into any of these further or help you think through the architecture/licensing fit for your specific projects.