Multi-tenancy

Multi-tenancy is how Authdog keeps data, configuration, and identities apart as your account grows. Once the layers are clear, the console and the CLI both make more sense: you always know which workspace you're changing.

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. The account boundary: billing, admin memberships, and the tenants you link under it.
• Tenant. The workspace for projects, team access, and domains. Day-to-day console work happens inside a selected tenant.
• Project. One application or product. It groups the environments that application ships through.
• Environment. The unit that actually serves auth. It has its own 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 only show tenants linked to the organization you've selected. See Organizations.

Tenant

This is the primary workspace: projects, members, verified domains, and settings for your company or for a client. Use a separate tenant when a product, a client, or a business unit shouldn't share that configuration.

Project

A project is one application or product. It keeps that application's environments away from your other products. MCP servers follow the same hierarchy, but they expose server-side tool endpoints instead of a client-facing sign-in flow.

Environment

This is the unit that serves auth. Each environment is fully self-contained. It has its own signing keys and public key, its own sign-in methods and SSO connections, its own user store, and its own authorization model. Environments map naturally onto deployment stages. See Deployments.

Why environment isolation matters

Keys belong to one environment, so a session issued in dev can never validate in production, and the reverse is true too. That gives you:

• Safe testing. Experiment in dev without touching production users or data. See Testing.
• Clean promotion. Configure a connection or a policy in staging, verify it, then apply the same shape to production.
• A smaller blast radius. 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, and an environment per stage.
• Several products: a project per product (same tenant or separate tenants), each with its own environments.
• Several business units or clients that need their own teams and billing: separate tenants, optionally under one organization.
• Don't treat an organization as a folder inside an environment. Organizations sit above tenants. End users live in environments.

Related