Tenancy

One project per tenant

Every tenant gets its own Neon project: a Postgres database with an identical schema, a Neon Auth instance with its own signing keys, and object-storage buckets. The project is the isolation boundary. A database branch forks the files with it, a suspended project takes its whole surface dark, and deleting a tenant is deleting one project.

No table carries a tenant id. A query runs against one tenant's connection and can see only that tenant's rows, so isolation does not depend on a filter being remembered.

Users do not cross tenants either. The same email signing in at two stores creates two accounts, one in each store's auth schema. There is no single sign-on and no tenant switcher.

The platform database

One small shared database holds the directory. Its public schema is the customer model; a sealed fleet schema maps a slug to the tenant's database, Data API and auth endpoints.

A project is a database. There is no staging sub-entity; a staging copy is a separate project the customer creates.

A project moves through provisioning, active, suspended, failed and deprovisioning. Only active resolves to a serving store. A gate can still read the status of a dark store, so the page can say why it is unavailable without being a way to reach it.

What the runtime can and cannot reach

The web runtime reads the directory through a role that can select a tenant's endpoints and nothing else. The tenant's own database URL carries no password: the runtime attaches the signed-in user's token and the database verifies it. Administrative credentials are never stored; operations derive them on demand from Neon, which is the source of truth.