Tenant Provisioning

Tenant provisioning is how a new tenant goes live, either as an individual sandbox or for an organisation. The account control plane (account.consystence.com) mints the tenant’s identity, places it on a hosting cell, sets up its subdomain, and has the cell create the tenant with its first Owner. This page covers how a tenant is requested, what provisioning does, how the tenant is reached at its subdomain, and how an owner deletes it.

For the topology these tenants land on, see Cell topology. For the managed cloud, see Cloud deployment. To attach a site server to a tenant, see site activation.

Public beta

The hosted service is in public beta. During the beta, free individual sandboxes and paid organisations are both arranged with our team: request access. The account control plane runs in production and provisions every kind of tenant described on this page.

How a tenant is requested

You request a tenant through the account control plane, the authority for tenant identity, slug uniqueness, DNS and the first Owner. A request for an unknown subdomain never creates a tenant on a cell.

• Free individual sandbox. During the beta, sandboxes are arranged on request (request access). An account holds at most one; it is created from the account console (New tenant, then Create a sandbox) with a chosen slug. The sandbox belongs to the account, not to an organisation, and lives at {slug}.consystence.dev. See Get a free sandbox for the slug rules.
• Free trial tenant. An organisation owner can create one free trial (simulation) tenant for the organisation, ever. It lives at {slug}.consystence.dev.
• Paid tenant. Integrator and Enterprise access is arranged with our team (contact us; see plans). Once the tier is granted to your organisation, an organisation owner provisions the tenant from the account console and chooses its slug. Enterprise tenants live at {slug}.consystence.com; Integrator tenants live at {slug}.consystence.dev.

What provisioning does

1. Checks the request. The account checks the slug, the allowance the request draws on (the account’s free sandbox, the organisation’s one trial, or its paid tier) and the platform’s rate limits. A rejected request stops here and never reaches a cell.
2. Places the tenant. The account chooses the tenant’s canonical domain (.com or .dev, from the kind of tenant above) and the cell that will host it. Placement is decided by the account alone.
3. Mints the tenant’s identity. The account mints an immutable id (org_ followed by 32 hex digits). The id is the tenant’s permanent identity; the slug is the label that becomes its subdomain. See Organisation & site model.
4. Creates the DNS record for the tenant’s subdomain, pointed at the hosting cell.
5. Creates the tenant on the cell, with its first Owner and one empty starter site.
6. Marks the tenant active.

Every step is safe to repeat. The id is minted once and reused on every retry, so an interrupted request resumes where it stopped and never creates a duplicate tenant.

Where the tenant’s plan includes cloud advisory AI, provisioning also links its hosting cell to an AI cell in the same region, if the cell has no AI cell yet and one is available. The link is made per cell, not per tenant.

The first Owner

The person who provisions a tenant becomes its first Owner, bound to their Entra identity (oid) when the tenant is created. A tenant is never created without an Owner. The account control plane is the authority for who holds a tenant’s Owner and Admin roles: owners and admins are managed on the account console and mirrored to the cell. Tenant roles are exactly owner, admin and member, assigned per tenant; see Roles. Per-tenant isolation is covered in Tenant isolation.

Reaching a tenant

A tenant is reached at {slug}.consystence.com (Enterprise) or {slug}.consystence.dev (Integrator tenants, sandboxes and trials). It becomes reachable once the DNS record for its subdomain points at the cell that hosts it; the cell then maps the request’s subdomain to the tenant. A site never gets a hostname of its own: it is reached under its tenant’s subdomain (see Organisation & site model).

Once a tenant is live, the account control plane is not in its request path: people reach the tenant at its subdomain, and the cell validates their Entra sign-in itself. See Authentication.

A standalone advisory AI web interface at consystence.io is planned as one address, with no per-tenant addresses: the tenant comes from the sign-in, with a default that a signed-in person can switch. It is not yet publicly available.

Cell placement

Each tenant is placed on exactly one cell and never spans cells. The account records which cell hosts the tenant; the cell’s host is never part of the tenant’s address. Today a single production cell hosts tenants. A dedicated cell for public sandboxes, separate from the cell for enterprise tenants, is planned. For the invariants and DNS routing, see Cell topology; for the broader picture, see the architecture overview.

Deleting a tenant

A tenant’s owner deletes it from the account console. The console shows a confirmation page that asks you to type the tenant’s slug, and only an owner of the tenant can complete the deletion. On confirmation, the tenant is removed from its cell and its DNS record is removed. Its directory entry, account-to-tenant associations and elevated roles are deleted straight away; deletion of its other operational stores is completed on request as part of offboarding.

The tenant’s operational journal is not deleted. It is kept as a permanent record and is no longer reachable through the platform. See the privacy policy.

Note

For the walkthrough of signing in, reaching a hosted tenant and joining it, see Cloud onboarding.