TanStack

Multi-tenancy is how Authdog isolates data, configuration, and identities across the platform hierarchy. Keeping the layers straight makes the rest of the console and CLI click into place.

The platform hierarchy

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

Organization: top-level account boundary — billing, admin memberships, and the tenants you link under it.
Tenant: workspace for projects, team access, and domains. Everything you do day to day in the console happens inside a selected tenant.
Project: one application or product. Groups the environments that application ships through.
Environment: the unit that serves auth. Fully self-contained keys, connections, user store, and authorization model.

Organization

An organization groups tenants under shared billing and administration. Not every account has one; when it does, tenant pickers and CLI /browse filter to tenants linked to the selected organization. See Organizations.

Tenant

The primary workspace: your company's (or client's) projects, members, verified domains, and settings. Use separate tenants to isolate different products, clients, or stages of the business that should not share configuration.

Project

A project represents one application or product. It keeps that application's environments separate from your other products. MCP servers follow the same hierarchy but expose server-side tool endpoints instead of client-facing auth flows.

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 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 by using that environment's public key; there is no cross-environment leakage.

Choosing your structure

One product, a few stages → one tenant, one project, environments per stage.
Several products → a project per product (same or separate tenants), each with its own environments.
Several business units or clients that need separate teams and billing umbrellas → separate tenants, optionally under one organization.
Never treat an organization as a folder inside an environment. Organizations sit above tenants; end users live in environments.

Organizations: account boundary, memberships, and billing
Tenants: create and manage tenant workspaces in the console
Projects: browse and create projects inside a tenant
Environments: manage deployment stages per project
Deployments: environments as deployment stages
Sessions & tokens: per-environment key isolation

Multi-tenancy