Plans and limits
| Plan | Zones |
|---|---|
free | 4 |
plus | 10 |
pro | 50 |
enterprise | 1000 |
How the gating works
Section titled “How the gating works”The CE core knows nothing about plans — before adopting a zone it asks a limits port, which the Cloud layer fills with the plan logic. When the limit is reached, the adoption is rejected with a message naming the current plan and its limit.
The advantage of this separation: CE code never needs touching for plans, and a self-hosted installation simply has no limits.
The subscription belongs to the tenant
Section titled “The subscription belongs to the tenant”The plan is a property of the organisation, not of the individual person. Users are seats included within it — nobody needs their own subscription. All limits (users, teams, domains, projects) are organisation limits.
Changing the plan
Section titled “Changing the plan”In the operator panel in the tenant detail, or via the API:
curl -X POST -H "X-Operator-Token: $DNSE_OPERATOR_TOKEN" \ -H "Content-Type: application/json" -d '{"plan":"pro"}' \ https://cloud.example.com/api/v1/operator/tenants/<id>/set-planA downgrade below the number of zones already in use removes nothing — existing zones remain, only further adoptions are blocked until the count is back below the limit.
Billing
Section titled “Billing”Invoicing happens externally. The platform delivers the data (organisation, plan, usage, lifecycle events) to separate billing software; there is deliberately no built-in billing.