Multi Tenancy | Docs

Multi-tenancy is how Authdog keeps data, configuration, and identities isolated between separate contexts — both your own environments (dev, staging, production) and your customers' organizations. It shows up at two levels, and keeping them straight makes the rest of the platform click into place.

Two levels of tenancy

Platform tenancy (this page) — how you structure your account: Tenant -> Projects -> Environments. This is operational isolation you control.
Application tenancy — how your B2B customers are isolated inside your app: Organizations. This is product isolation your users see.

They compose: a single environment serves many organizations.

The platform hierarchy

Code

Tenant
└── Project (an application / product)
    └── Environment (dev · staging · production)
        ├── signing keys + public key (pk_...)
        ├── sign-in methods & connections
        ├── users
        └── authorization model (RBAC | ABAC | FGA)

Tenant

The top-level account boundary — your company's workspace. It owns billing, members, and one or more projects. Everything you do in the console happens inside a tenant.

Project

A project represents one application or product. It groups the environments that application ships through and keeps its configuration separate from your other products.

Environment

The unit that actually serves auth. Each environment is fully self-contained: its own signing keys and public key, its own enabled sign-in methods and SSO connections, its own user store, and its own authorization model. Environments map naturally to deployment stages — see Deployments.

Why environment isolation matters

Because keys are per-environment, a session minted in dev can never validate in production, and vice versa. That gives you:

Safe testing — experiment in dev without any risk to production users or data. See Testing.
Clean promotion — configure a connection or policy in staging, verify it, then apply the same shape to production.
Blast-radius control — rotating or leaking a dev key has no effect on production.

Your app selects the environment simply by using that environment's public key — there is no cross-environment leakage.

Application-level multi-tenancy

When your product itself is multi-tenant — many customer companies, each with their own users — model those customers as Organizations inside a single environment. Users can belong to multiple organizations, roles are scoped per organization, and the active organization travels in the session so authorization decisions are naturally org-aware.

Code

Environment: production
├── Organization: acme     (members, org roles, SSO connection)
├── Organization: globex    (members, org roles)
└── Organization: initech

Enterprise customers can even bring their own IdP and directory: SSO connections and provisioning are configured per organization.

Choosing your structure

One product, a few stages -> one project, environments per stage.
Several products -> a project per product, each with its own environments.
B2B customers inside a product -> organizations within the production environment.

Organizations — application-level tenancy in depth
Deployments — environments as deployment stages
Provisioning — per-organization directory sync
Sessions & tokens — per-environment key isolation

Multi-tenancy