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.
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.
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 -> unsupportedSee roots and composition, deployment, and resources and lifecycle, then follow the multi-tenant platform recipe.