Skip to main content

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.

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 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, diff, merge, history, and 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).
PropertyWhat it tracks
NameIdentifier shown in the switcher (master, staging, feature-auth).
ParentThe environment this one was branched from. Master has no parent.
Branch modefull (schema + data) or system (schema only).
StatusOne of active, branching, merging, error, archived.
Branched atWhen this environment was created.
ChildrenEnvironments branched from this one.

​
Branch modes

When you create a new environment, you pick how the source database is cloned:
ModeWhat’s copiedWhen to use it
FullSchema and all row data.Realistic data needed — QA, staging, performance testing.
SystemSchema 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.

​
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.
StatusMeaning
activeFully operational and available.
branchingBeing created — database cloning in progress.
mergingA merge is being applied to this environment.
errorAn operation failed; the environment may be inconsistent.
archivedSoft-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.

​
Where to go next

Creating

Branch a new environment with the right mode and copy flags.

Tree

Visualize the parent-child hierarchy and plan merge strategies.

Diff

Compare two environments’ schemas with forward-only semantics.

Merge

Cherry-pick changes from one environment to another, transactionally.

History

Audit trail of every merge and migration.

Backups

Automatic pre-merge backups, manual snapshots, and restore.

Deleting

Permanently remove an environment.

Configuration

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 — 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.