Skip to content
Odysseus

Tenancy and isolation

The problem

Section titled “The problem”

A shared platform fails in one of two directions. Either isolation is a convention — a naming scheme everyone promises to respect — and one mistaken request reads or overwrites somebody else’s work; or isolation is a separate installation per tenant, and the cost of the platform multiplies by the number of tenants.

Convention fails quietly. A listing endpoint that forgets its filter returns every tenant’s records and looks exactly like a listing endpoint that works.

How the platform solves it

Section titled “How the platform solves it”

Every record the platform stores is written under the tenant that owns it, and the client that reads and writes those records takes the tenant as an argument rather than as an option. A read that does not name a tenant does not return everything; it does not compile.

That boundary covers all of it, not just deployments: nodes, networks, secrets, jobs, schedules and their run history each belong to exactly one tenant. Placement is bounded by the same rule — a tenant’s deployment can only be placed on a node that tenant holds.

Credentials follow the tenant too. A secret is referenced by path, never carried in the description, and the path is resolved inside the owning tenant’s own storage at dispatch time. Two tenants can use identical paths and never see each other’s material.

Names are scoped, not global. Two tenants may both run a deployment called api, and neither can address the other’s.

Not this

This page is not about user accounts, roles or sign-in. A principal’s rights within a tenant — who may build and who may run — is a separate model with its own vocabulary.

It also does not describe network-level isolation between containers, which is a property of the networks a deployment joins rather than of tenancy.

Where to see it

Section titled “Where to see it”