Cell Topology & Control Plane

Consystence scales past a single deployment by running independent cells, coordinated by a thin account control plane that sits above them. A cell is a self-contained server deployment that runs tenants; the control plane (consystence-account) is the identity front door, the tenant directory, the DNS router, and the one-shot provisioning authority. It never owns a tenant’s membership, configuration, or runtime state — those live entirely in the cell.

This page describes the control plane, the cell model, how a cell establishes trust with the account at first boot, and how an org is provisioned onto a cell.

Not yet GA

The account control plane runs in production and drives tenant provisioning end-to-end today, gated behind operator approval — self-serve signup is not yet GA. Treat the host patterns and behaviours here as design-of-record that may still move. Billing and the licence-pool / site-activation flow are likewise live; only the marketplace remains roadmap (see Licensing).

Two planes, one separation of concerns

The platform deliberately splits into a control plane and a set of cells, each owning a strict slice of responsibility.

Concern	Owner
Authentication (issues CIAM tokens)	Entra External ID at id.consystence.com
Tenant identity, DNS, routing, entitlement, provisioning, site declaration/allocation (tier-capped), the first owner	Control plane (account.consystence.com)
Membership, configuration authoring, site operation, devices, tenant runtime	The cell that hosts the org

The control plane is a stateless directory/routing API (account.consystence.com) plus a separate console UI tier. It is an OIDC relying party of id.consystence.com — it consumes Entra identity, it does not issue it. Critically, the control plane is not in a cell’s authentication path: each cell validates CIAM bearer JWTs directly against the Entra issuer, so a cell keeps working — and stays offline-capable for site logins — whether or not the account is reachable. See Authentication for the MultiAuth scheme selector.

What a cell is

A cell is an independent, always-online server deployment — its own Orleans cluster, its own PostgreSQL, its own historian — bound to the tenants it hosts. You scale by adding a cell rather than by growing one; tenants migrate between cells only on request. Four invariants are binding on the design:

1. The cell host is never surfaced. Users only ever see the org subdomain, never the cell host.
2. A tenant’s home cell is always a lookup, never hardcoded.
3. A customer never spans a cell — one org lives wholly on one cell.
4. A cell is IaC-reproducible — every cell is the same reproducible infrastructure unit.

A cell never assumes a tenant exists: it does not self-provision on a request for an unknown tenant. It runs only what the control plane has provisioned onto it.

Note

A cell is cloud infrastructure operated by Consystence; the site server (which may be offline at a real plant) is a member of a tenant that lives on a cell — it is not itself a cell. The same codebase is published as either a cloud/cell server or a site server. See the four-tier architecture.

Domain families

Each domain family maps to one role in the topology. A site is always a path under an org’s subdomain (/sites/{code}) — never its own hostname. See the org & site model for the full hierarchy.

Host pattern	Role	Notes
{slug}.consystence.com	Enterprise-family org	Verified, slug-gated (manual approval) — namespace protection against squatting
{slug}.consystence.dev	Integrator-family orgs and individual sandboxes	Development-tier domain; sandboxes are free, auto-provisioned, self-chosen slug (validated DNS label); HSTS-preloaded
{slug}.consystence.io	Per-tenant AI advisory (IO) chat surface	Provisioned with the tenant; the consystence.io apex is the sign-in / tenant-pick door
account.consystence.com	Control plane (directory, routing, signup, provisioning)	Stays .com for every tier
id.consystence.com	Entra External ID (CIAM)	Issues the bearer JWTs every cell validates
api.consystence.com	Reserved for a future public API	No committed contract — see the gateway

Org tiers group into two families — an enterprise (operations) family on .com and an integrator (development) family on .dev, with individual sandboxes also on .dev. .app is reserved.

Cell enrolment & trust

Before a cell can host tenants it establishes mutual, operator-approved trust with the account at first boot; a valid enrolment is never auto-trusted, and a platform operator must explicitly approve the cell before it goes active. The credentials issued at enrolment are rotatable and revocable by their issuer, so a compromised cell can be cut off at once. Cell identity is deliberately cloud-agnostic infrastructure identity — not Entra — so a cell can run on any cloud without coupling to a single identity provider, while human and tenant identity remains the Entra oid.

Org provisioning

The account is the provisioning authority and chokepoint — it owns entitlement checks, rate limiting, tenant identity, slug uniqueness, DNS, and the seeding of the first owner. The cell is the executor: it creates the org runtime and recognises the elevated roles, but it never decides whether to provision.

Tenant identity is an immutable identifier minted at the account — the directory’s primary key and the identity the cell adopts. The cell does not mint its own; it adopts exactly the identity the account assigns and continues to use the org slug as its operating key.

What the account hands the cell

To provision, the account calls the cell over the enrolment-established machine credential (not an interactive platform-operator identity) and hands it the tenant identity, slug, org type, licence tier, the first owner, and any domain bindings. The cell adopts the organisation under that identity and confirms adoption. Only the identity, slug, and first owner are enforced today; org type, licence tier, and domain bindings are accepted for forward-compatibility. Provisioning is safe to re-run — a repeat call for an organisation that already exists returns the existing organisation rather than creating a duplicate.

The first owner

The first owner is account-authoritative: the account records the owner and delivers it to the cell alongside the organisation; the cell recognises owner and admin but does not originate them. A named invariant pins the safety property — an org is never created-but-ownerless: org creation and the owner landing together (or complete together on a retry), or the call fails and no organisation is left without an owner. Roles are exactly owner / admin / member; see Roles.

End-to-end flow

sequenceDiagram
    participant Op as Platform operator
    participant Acc as Account control plane
    participant Cell as Cell

    Op->>Acc: approve new cell (mutual trust established)
    Note over Acc: entitlement check · mint tenant identity · assign subdomain
    Acc->>Cell: provision organisation (with its first owner)
    Cell-->>Acc: organisation adopted

Account-side, provisioning is a durable, resumable sequence: the entitlement and rate-limit checks run at the front door and never reach the cell; the account then assigns the canonical subdomain and target cell, records the new tenant, calls the cell, and marks the tenant active on success. Every step is safe to re-run, so an interrupted provision resumes without creating a duplicate.

For where cells sit in the wider compute stack, see the architecture overview; for the runtime that talks to plant equipment, see the edge.