**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](/docs/concepts/organizations)**: 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](/docs/users), and [authorization](/docs/concepts/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](/docs/concepts/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](/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 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 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](/docs/concepts/organizations).
- Never treat an organization as a folder *inside* an environment. Organizations sit above tenants; end users live in environments.

## Related

- [Organizations](/docs/concepts/organizations): account boundary, memberships, and billing
- [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
- [Deployments](/docs/deployments): environments as deployment stages
- [Sessions & tokens](/docs/concepts/sessions-tokens): per-environment key isolation