Skip to main content
Almost everything in your backend is per-environment. When you switch environments using the switcher at the top of the project chrome, the entire Backend Console reloads in that environment’s context — different data, different roles, different secrets, different integration credentials. This page is the index of what’s scoped per-environment with cross-links to each setting.

​
The full per-environment scope

Every block below is independent across environments. Editing it in staging does not affect master. For the branch-time copy mechanics — which checkboxes copy what — see Creating environments.

​
Why secrets aren’t copied

Authentication provider secrets, OAuth credentials, and integration API keys (Stripe, SendGrid, etc.) are deliberately excluded from branch-time copying:
  • A dev secret leak shouldn’t compromise production.
  • Different environments often use different vendor accounts (test mode vs. live mode for Stripe; sandbox vs. production for OAuth providers).
  • Re-entering credentials per environment makes the security boundary explicit and reviewable.
When you branch a new environment, the auth provider configuration appears with the same fields but the secret values blank — you re-enter them in the new environment before activating the provider.

​
Per-environment context propagation

When you switch environments, the platform reloads the entire console in the new context. Behind the scenes:
  • API requests gain an environment header that routes to the right database.
  • The GraphQL and REST API endpoints are per-environment URLs.
  • Generated API tokens are scoped to a single environment and rejected by others.
  • Custom function deployments are per-environment.
There’s no path by which a request to dev accidentally touches production data — the routing happens server-side based on the environment header.

​
Common patterns

​
What’s not per-environment

A small number of things live at the project level — they’re shared across every environment:
  • The project itself (name, owner, billing).
  • Workspace memberships and team-level roles.
  • Project-level settings on the Frontend (UI, branding) that apply across environments.
If you need different values for those across environments, model them as per-environment configuration — for example, store frontend variants behind environment variables rather than at the project level.

​
FAQ

API keys are environment-scoped — issued for a single environment and rejected by others. Generate a new key in production and use that. Same applies to integration credentials and OAuth secrets.
No. Roles live in each environment’s database, so changes don’t propagate. To bring a role change from staging to master, merge — RBAC schema travels with the merge.
The copy flags only fire at branch time. After branching, edit each environment individually. For values you want to keep in sync, use a workspace-level secret store and reference it from each environment.
The dashboard scopes to the active environment. To inspect another environment’s configuration, switch to it. For programmatic access, the GraphQL API accepts an environment header — you can query any environment’s state without switching the dashboard.
Treat environment variables as the source-controlled boundary. Commit a .env.example listing every key without values, and use the Environment Variables UI to set per-environment values. Avoids checking secrets into git while keeping the variable surface explicit.