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 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 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 for seeding users, validating the authdog-session, and keeping the dev public key (never production secrets) in CI.