A multi-tenant product has two distinct systems: the released control-plane workload and the customer-created resource instances it manages. One plans and releases the first without pretending every customer action is a new One project lifecycle.
Release a bounded control plane
The control-plane root closes its API, UI, workers, state, provider bindings, artifacts, authority, quotas, observations, and supported instance catalog. Its immutable release envelope contains every implementation and capability it may offer at runtime.
Adding a runtime choice that needs new code, provider support, authority, resource class, region, or cost bound requires a new release. A customer request cannot trigger ambient provider discovery or execute the One CLI.
Give instances product-owned identity
Tenants, subscriptions, projects, game servers, databases, workspaces, or other managed objects retain identities and intent owned by the product domain. The selected provider supplies exact physical instance bindings, fences, receipts, and observations.
The product does not expose a provider handle as its domain identity. This allows replacement, recovery, and federation without rewriting customer meaning.
Constrain the runtime envelope
At request time, the control plane may choose an admitted region, size, version, or extension already present in the release plan. Runtime policy checks tenant quota, price, data residency, isolation, availability, and authority before binding an instance.
A provider profile that proves one stateless process is not enough to claim a multi-instance stateful host. The host must prove capacity, isolation, persistence, addressing, upgrade, observation, fencing, and reconciliation.
Quotas, budgets, and fairness
Quotas are hard admission bounds; budgets are observed consumption. The released control plane reserves a tenant's quota before allocating a resource and releases the reservation when the instance is deleted, so two concurrent requests cannot oversubscribe the same allowance. Fairness is enforced within the provider's authority domain: a tenant at its limit is declined with a typed domain outcome while other tenants continue.
Budget dimensions include compute, storage, network, instance count, and monetary cost. Consumption is observed and attributed per tenant; the product shows the resource's work and next action, and exact provider and cost evidence stays in a deliberate inspection view. A provider profile that proves one stateless call is not evidence of multi-instance quota or fairness behavior. See resources and lifecycle and cost and budgets.
Isolate every tenant dimension
Isolation covers identity, data, compute, network, secrets, logs, metrics, history, quotas, encryption, support access, backup, export, and deletion. Shared physical infrastructure is allowed only where the selected provider proves the requested semantic isolation.
Adaptive routing uses separate grants for each provider member. Health or capacity cannot broaden the union of accessible tenant data.
Reconcile customer operations durably
Create, resize, suspend, migrate, restore, and delete requests become fenced domain operations with exact intent and provider receipts. Unknown outcomes are observed before retry. User-facing status describes the resource's work and next action, while exact provider and reconciliation evidence remains in a deliberate inspection view.
Deployment and control-plane choices
The released control plane is one ordinary deployment; customer create, resize, suspend, migrate, restore, and delete requests are product operations that use already selected provider bindings. Reconciliation may be embedded in the released apply process, projected to Kubernetes or an exact GitOps artifact, or delegated to a persistent controller, but the choice is made when the control plane is planned and released, not per customer request.
A customer request never invokes the One CLI, discovers a provider, selects an unplanned artifact, or replaces an Authority epoch. Where a hosted console is selected, One Cloud consumes the same owner records and adds no authority of its own.
Example
An illustrative released envelope bounds customer choices:
Vanilla 1.22 -> Small, Medium
Paper 1.22 -> Medium, Large
tenant quota -> 10 servers, 200 GiB
unlisted distribution -> unsupportedAvailability and evidence
This page and its
multi-tenant platform recipe are
illustrative end-product material. There is no checked-in multi-tenant
control-plane consumer yet; any .one or Rust shown in the recipe is
end-product syntax, not a current test path.
The current owning contracts are Planning, Deployment, Authority, and Resources, which decide requirement closure, provider placement, grants, and resource lifecycle respectively. A fixture-backed product view must be identified as fixture-backed and cannot be presented as hosted or provider-observed fact.
Canonical owners: Planning, Deployment, Authority, Resources.
See roots and composition, deployment, and resources and lifecycle, then follow the multi-tenant platform recipe.