Enterprise Isolation

Enterprise tenants are isolated by design.

If you are an enterprise customer, your data is your data. We do not place enterprise tenants into a shared database server and try to recover isolation later with application filtering alone. Each enterprise tenant is bound to its own dedicated database server.

What that means

Your dashboard traffic resolves to your tenant from its exact hostname.
Your API traffic resolves to your tenant from tenant-bound API keys.
Your tenant maps to one dedicated database server.
Requests fail closed if tenant resolution or database mapping does not match.

Why we do it this way

Dedicated database servers give enterprise tenants a clearer isolation boundary.

They reduce the risk of cross-tenant data exposure.
They simplify backup, restore, and operational boundaries.
They make tenant ownership and routing rules easier to reason about.
They avoid relying on client-supplied tenant selectors or weak shared-database assumptions.

Dashboard and API routing

For the dashboard, tenant resolution comes from the exact tenant hostname. If the hostname is not an exact match, the request does not enter tenant-scoped dashboard content.

For the API, tenant resolution comes from the presented API key. The client does not choose the tenant or database server directly. The orchestrator verifies the key through a dedicated key service, receives the trusted tenant and database server binding, and then serves the request against that tenant’s environment.

Isolation contract

The platform treats these as hard rules for enterprise tenants:

A user belongs to exactly one tenant.
A user session must match the tenant resolved from the dashboard hostname.
A tenant-bound API key must resolve to exactly one tenant.
A tenant must map to exactly one dedicated database server.
Any missing value or mismatch is rejected.

Current scope

This enterprise model is the current direction for isolated enterprise environments. It is separate from any future shared SaaS tier decisions.