In Authdog, environments are your deployment stages. A project has dev, staging, and production environments, and each one is fully isolated — its own signing keys, connections, user store, and public key. Promoting auth from development to production means promoting configuration between environments, not migrating infrastructure. See [Multi-tenancy](/docs/concepts/multi-tenancy) for how tenants, projects, and environments nest.

## Environments as stages

Each environment maps to a deployment stage:

- **dev** — for local and iterative development.
- **staging** — for pre-production verification.
- **production** — for live traffic.

Because environments are isolated, work in dev can never touch production users or keys.

## Per-environment keys and config

Every environment has its own signing keys and its own public key (`pk_...`). Your app is configured with the public key for the environment it targets, and it validates sessions against that key. Connections (social, SSO), theming, add-ons, and policies are all set per environment. Keep each environment's public key with that environment's build — the dev key belongs in dev, the production key in production.

## Promoting configuration

As a change is ready, promote configuration from dev toward production. This moves settings — connections, theming, add-ons, policies — up the stages so production mirrors what you verified earlier, without hand-copying settings between consoles. Signing keys remain distinct per environment; only configuration is promoted.

## Custom domains

Point a custom domain at the identity/portal host so the [Account portal](/docs/account-portal) and identity endpoints run under your own domain rather than the default Authdog host. Custom domains are configured per environment, so production can use your branded domain while dev uses the default.

## Edge validation

Authdog runs on an edge runtime (Cloudflare Workers), so session validation happens close to your users rather than a single region. This keeps auth checks fast wherever requests originate, whether they hit the hosted portal, components, or your own backend.

## Testing before you promote

Verify each stage against its own keys and users before promoting. See [Testing](/docs/testing) for seeding users, validating the `authdog-session`, and keeping the dev public key (never production secrets) in CI.