> ## Documentation Index > Fetch the complete documentation index at: https://archie.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Configuration > What's scoped per-environment — the data model, app services, settings, and integrations that each environment maintains independently. 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`. | Resource | Where to configure | Copied at branch time? | | -------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | **Data Model schema** | [Backend → Data Model](/features/backend/data-model/overview) | Always (Full or System mode) | | **Authentication providers** | [App Services → Authentication Providers](/features/backend/app-services/authentication-providers/overview) | Provider records yes; **secrets never** | | **Role-based access** | [App Services → Role-Based Access](/features/backend/app-services/role-based-access) | Always (lives in the cloned database) | | **File storage providers** | [App Services → File Manager](/features/backend/app-services/file-manager) | Optional, per checkbox | | **Custom APIs (gateway routes)** | [App Services → Custom APIs](/features/backend/app-services/custom-apis) | Optional, per checkbox | | **Network policy (CORS, rate limits)** | [Backend → Settings → Network](/features/backend/settings/network) | Optional, per checkbox | | **API keys** | [Backend → Settings → API Keys](/features/backend/settings/api-keys) | Never (issued per environment) | | **Environment variables** | [Backend → Settings → Environment Variables](/features/backend/settings/environment-variables) | Optional, per checkbox | | **Integrations** | [Backend → Integrations](/features/backend/integrations/overview) | Provider records yes; **credentials never** | | **Migration history** | [Environments → History](/features/backend/environments/history) | Never (audit trail per-environment) | | **Backups** | [Environments → Backups](/features/backend/environments/backups) | Never (snapshots per-environment) | For the branch-time copy mechanics — which checkboxes copy what — see [Creating environments](/features/backend/environments/creating#what-s-copied). ## 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 | Pattern | How to configure it | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Test Stripe keys in dev, live keys in prod** | Configure the [Stripe integration](/features/backend/integrations/stripe) with test keys in `dev`, live keys in `master`. The Stripe SDK in your code is the same; the credentials it uses are per-environment. | | **Looser CORS in dev, stricter in prod** | Set permissive origins in `dev`'s [Network settings](/features/backend/settings/network), specific origins in `master`. Branch-time copying lets you start matching, then diverge. | | **A staging email sender** | Configure [SendGrid](/features/backend/integrations/sendgrid) with a staging-only sender address in `staging` so test emails don't appear to come from your production domain. | | **Feature flag for a beta** | Set a `BETA_FEATURE_ENABLED` [environment variable](/features/backend/settings/environment-variables) to `true` in `staging` and `false` in `master`. Promote when ready. | | **Restricted access to staging** | Use a dedicated [API key](/features/backend/settings/api-keys) per environment. Revoking the staging key doesn't affect production. | ## 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](/features/backend/environments/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](/features/backend/settings/environment-variables) UI to set per-environment values. Avoids checking secrets into git while keeping the variable surface explicit.