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.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.
The full per-environment scope
Every block below is independent across environments. Editing it instaging does not affect master.
| Resource | Where to configure | Copied at branch time? |
|---|---|---|
| Data Model schema | Backend → Data Model | Always (Full or System mode) |
| Authentication providers | App Services → Authentication Providers | Provider records yes; secrets never |
| Role-based access | App Services → Role-Based Access | Always (lives in the cloned database) |
| File storage providers | App Services → File Manager | Optional, per checkbox |
| Custom APIs (gateway routes) | App Services → Custom APIs | Optional, per checkbox |
| Network policy (CORS, rate limits) | Backend → Settings → Network | Optional, per checkbox |
| API keys | Backend → Settings → API Keys | Never (issued per environment) |
| Environment variables | Backend → Settings → Environment Variables | Optional, per checkbox |
| Integrations | Backend → Integrations | Provider records yes; credentials never |
| Migration history | Environments → History | Never (audit trail per-environment) |
| Backups | Environments → Backups | Never (snapshots per-environment) |
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
devsecret leak shouldn’t compromiseproduction. - 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.
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
environmentheader 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.
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 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, specific origins in master. Branch-time copying lets you start matching, then diverge. |
| A staging email sender | Configure 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 to true in staging and false in master. Promote when ready. |
| Restricted access to staging | Use a dedicated API key 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.
FAQ
Why do my staging API keys not work in production?
Why do my staging API keys not work in production?
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.
If I edit an RBAC role in staging, does master get the change?
If I edit an RBAC role in staging, does master get the change?
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.Can I bulk-copy configuration after I've already branched?
Can I bulk-copy configuration after I've already branched?
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.
Where do I see what's configured in another environment without switching?
Where do I see what's configured in another environment without switching?
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.What's the cleanest way to manage environment-specific config in source control?
What's the cleanest way to manage environment-specific config in source control?
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.