# Multi-tenant platforms

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:

```text
Vanilla 1.22 -> Small, Medium
Paper 1.22 -> Medium, Large
tenant quota -> 10 servers, 200 GiB
unlisted distribution -> unsupported
```

See [roots and composition](/one/model/composition),
[deployment](/one/platform/deployment), and
[resources and lifecycle](/one/model/resources), then follow the
[multi-tenant platform recipe](/one/examples/multi-tenant-platform).