**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/concepts/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/concepts/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.

<div class="orgtree">
  <div class="orgtree__root">
    <span class="orgtree__root-icon">
      <svg viewBox="0 0 24 24" fill="none" aria-hidden="true"><rect x="4" y="4" width="16" height="16" rx="3" stroke="currentColor" stroke-width="1.7"/><path d="M8 9h8M8 13h5M8 17h3" stroke="currentColor" stroke-width="1.7" stroke-linecap="round"/></svg>
    </span>
    <div>
      <span class="orgtree__eyebrow">Environment</span>
      <strong>Production</strong>
    </div>
  </div>
  <div class="orgtree__branches" aria-hidden="true"></div>
  <div class="orgtree__children">
    <div class="orgtree__org orgtree__org--featured">
      <span class="orgtree__eyebrow">Organization</span>
      <strong>Acme</strong>
      <div class="orgtree__features">
        <span>Members</span>
        <span>Roles</span>
        <span>SSO</span>
      </div>
    </div>
    <div class="orgtree__org">
      <span class="orgtree__eyebrow">Organization</span>
      <strong>Globex</strong>
      <div class="orgtree__features">
        <span>Members</span>
        <span>Roles</span>
      </div>
    </div>
    <div class="orgtree__org">
      <span class="orgtree__eyebrow">Organization</span>
      <strong>Initech</strong>
      <div class="orgtree__features">
        <span>Members</span>
        <span>Roles</span>
      </div>
    </div>
  </div>
  <p class="orgtree__caption">One environment, with access isolated per organization</p>
</div>

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

## Related

- [Tenants](/docs/console/tenants) — create and manage tenant workspaces in the console
- [Projects](/docs/console/projects) — browse and create projects inside a tenant
- [Environments](/docs/console/environments) — manage deployment stages per project
- [Organizations](/docs/concepts/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