**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](/docs/organizations)**. This is product isolation your users see.

They compose: a single environment serves many organizations.

## The platform hierarchy

```
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](/docs/concepts/sessions-tokens), its own enabled sign-in methods and SSO connections, its own [user store](/docs/users), and its own [authorization model](/docs/concepts/authorization). Environments map naturally to deployment stages — see [Deployments](/docs/deployments).

## Why environment isolation matters

Because keys are per-environment, a [session](/docs/concepts/sessions-tokens) 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](/docs/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](/docs/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](/docs/concepts/authorization) decisions are naturally org-aware.

```
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](/docs/concepts/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](/docs/organizations) within the production environment.

## Related

- [Organizations](/docs/organizations) — application-level tenancy in depth
- [Deployments](/docs/deployments) — environments as deployment stages
- [Provisioning](/docs/concepts/provisioning) — per-organization directory sync
- [Sessions & tokens](/docs/concepts/sessions-tokens) — per-environment key isolation