Orbit Handbook
MarkdownOpen in ClaudeOpen in ChatGPT

How to Mirror Production in Staging

2026-06-24

Staging
only earns its keep when a green deploy there means something about
production. Here is the setup we run, using nothing but
environment overlays.

Keep the overlay thin

The whole trick is what staging is allowed to change. Ours differs from
production by exactly three lines:

environments:
  staging:
    url: https://staging.hello.example
    replicas: 1
  production:
    url: https://hello.example
    replicas: 3
    protect: true

Same build, same health checks, same release strategy. If a key appears in
one overlay and not the other, that is drift you chose, visible in the file,
reviewable in the diff.

Promote, never rebuild

The habit that makes mirroring real:

orbit deploy --env staging     # build once, verify in staging
orbit promote --from staging --to production

A promote moves the exact release that passed staging - same artifact, same
resolved config, only the overlay differs. Rebuilding "the same commit" for
production quietly reintroduces everything mirroring exists to remove: new
base image, new dependency resolution, new build flags.

Let the plan police it

Drift still creeps in - a hotfix applied by hand, a console tweak. orbit plan reports it under drift, and our CI runs it nightly against both
environments:

orbit plan --env production --json | jq -e '.drift | length == 0'

The night that check first went red it caught a manually-raised replica count
that had been "temporary" for five weeks. The overlay got a fourth line;
the habit got a blog post.