---
title: "How to Mirror Production in Staging"
description: "A three-line overlay, promote-not-rebuild, and a nightly drift check."
date: "2026-06-24"
tags: ["howto"]
canonical: "https://orbit-handbook.sitesmojo.com/blog/how-to-mirror-production-in-staging/"
---

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](/docs/configuration/).

## Keep the overlay thin

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

```yaml
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:

```bash
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:

```bash
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.