> ## 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.
# Overview
> Environments are isolated copies of your backend that let you develop, test, and ship changes safely without affecting production.
Environments are isolated copies of your backend that let you develop, test, and ship changes safely without affecting production. Every project starts with a single **master** environment. From there, you branch new environments — `staging`, `feature-auth`, `qa-sprint-12` — that inherit the schema (and optionally the data and configuration) of their parent and run in complete isolation.
Changes in one environment don't propagate to another until you explicitly [merge](/features/backend/environments/merge) them.
## How you reach Environments
Environments don't have a dedicated entry in the Backend sidebar. You access them through the **environment switcher** at the top of the project chrome — the dropdown that shows the active environment's name. From there you can:
* Switch to a different environment (the entire Backend Console reloads in that environment's context).
* Open the create-environment modal.
* Open the [environment tree](/features/backend/environments/tree), [diff](/features/backend/environments/diff), [merge](/features/backend/environments/merge), [history](/features/backend/environments/history), and [backups](/features/backend/environments/backups) views.
## The branching model
Environments form a parent-child tree rooted at `master`. Each branch carries metadata — name, status, branch mode, parent, branched-at timestamp, and the list of children — that drives the rest of the surface (diff target selection, merge direction, restore scope).
| Property | What it tracks |
| --------------- | ----------------------------------------------------------------------- |
| **Name** | Identifier shown in the switcher (`master`, `staging`, `feature-auth`). |
| **Parent** | The environment this one was branched from. Master has no parent. |
| **Branch mode** | `full` (schema + data) or `system` (schema only). |
| **Status** | One of `active`, `branching`, `merging`, `error`, `archived`. |
| **Branched at** | When this environment was created. |
| **Children** | Environments branched from this one. |
## Branch modes
When you create a new environment, you pick how the source database is cloned:
| Mode | What's copied | When to use it |
| ---------- | ---------------------------- | --------------------------------------------------------- |
| **Full** | Schema **and** all row data. | Realistic data needed — QA, staging, performance testing. |
| **System** | Schema only. No row data. | Clean dev environment, or you'll seed the data yourself. |
For full coverage of branch modes and the configuration-copy flags, see [Creating environments](/features/backend/environments/creating).
## Status lifecycle
Environments transition through five states. The platform uses these to prevent conflicting operations — you can't delete an environment that's `merging`, can't merge into one that's `branching`.
| Status | Meaning |
| ----------- | ----------------------------------------------------------------------------- |
| `active` | Fully operational and available. |
| `branching` | Being created — database cloning in progress. |
| `merging` | A merge is being applied to this environment. |
| `error` | An operation failed; the environment may be inconsistent. |
| `archived` | Soft-deleted; data preserved but the environment is hidden from the switcher. |
## Isolation guarantees
Environments are designed for hard isolation between development stages:
1. **Storage isolation** — each environment has its own dedicated PostgreSQL database. A bug or destructive operation in `dev` cannot reach `production`.
2. **Configuration scoping** — every backend setting is per-environment. Auth providers, API keys, RBAC roles, custom APIs, file storage, environment variables, and integration credentials are all independent.
3. **Context propagation** — when you switch environments, the entire Backend Console reloads in that environment's context. The same applies to API requests via the `environment` header. There's no path by which `dev` traffic accidentally touches `production` data.
For the full list of what's scoped per-environment, see [Configuration](/features/backend/environments/configuration).
## Where to go next
Branch a new environment with the right mode and copy flags.
Visualize the parent-child hierarchy and plan merge strategies.
Compare two environments' schemas with forward-only semantics.
Cherry-pick changes from one environment to another, transactionally.
Audit trail of every merge and migration.
Automatic pre-merge backups, manual snapshots, and restore.
Permanently remove an environment.
What's scoped per-environment, with cross-links to each setting.
## FAQ
Yes — branch as many as you want. Each one is independent, so it's reasonable to have a long-lived `master` and `staging` plus a handful of short-lived `feature-*` environments for in-progress work.
No. Environments are isolated. Schema changes propagate only when you explicitly [merge](/features/backend/environments/merge) — the cherry-pick UI lets you pick which changes to apply.
It's the root of the tree and can't be deleted or renamed. Other environments can be deleted; `master` always exists so the project always has a baseline.
Nothing. Switching only changes which environment your console session is pointed at. The previous environment continues running, holds open connections, and serves traffic from any clients still using it.
Not as a dedicated menu entry — environments are surfaced through the switcher at the top of the project chrome. The docs cover the full surface; the product UI threads the actions through the switcher dropdown.