Changes

A change is a difference between an environment and its parent in the inheritance chain. The Changes view is your diff browser; the Merge action is how you copy those differences across.

Production  ◀── Staging  ◀── Development
   (root)      (3 changes)   (1 change)

Production is the source of truth and has no parent — so it always shows zero changes. Staging compares to Production. Development compares to Staging.

Where to find changes

Two entry points:

1. Environments tab — the arrows between env cards show the change count. Click an arrow to jump straight to the diff.
2. Environment detail page — open any non-prod env; the Changes tab is the default.

What the diff shows

Changes are grouped into five categories, each collapsible:

Each row shows the before (parent value) and after (this env's value), color-coded:

The Merge workflow

Once you've reviewed the diff, the Merge action copies one env's config into another.

1. From the Environments tab, click Merge environments. From the Changes tab, the same button is in the header.
2. The merge dialog asks for:
   • Source — the env to copy from (its config wins).
   • Target — the env to copy into (its config is overwritten where they differ).
   • Categories to include — checkboxes for Variables, Permissions, Groups, Addons. Uncheck any you want to skip.
3. Click Merge. The target environment is updated atomically.

After the merge, the Changes view between source and target shows zero changes for the merged categories.

Common promotion flows

Promote dev → staging → production

The classic forward path. You experiment in Development, validate in Staging, then ship to Production.

1. Make changes in Development.
2. Merge Development → Staging (review diff first).
3. Smoke test on a Staging server.
4. Merge Staging → Production.

Sync down a hot-fix

You patched a value directly in Production (e.g. emergency tax fix). Now Staging and Development are out of sync. Mirror it down:

1. Merge Production → Staging.
2. Merge Production (or Staging) → Development.

Selective promotion

You changed three things in Development but only want to ship one of them.

1. Roll back the two you DON'T want to ship in Development (Variables tab → Reset).
2. Now the Development → Staging diff only shows what you want.
3. Merge with all categories on.

Or use the category checkboxes to merge just Permissions without touching Variables, etc.

Reverse merges (sync down)

Merge is one-way per call: source → target. Both directions are allowed:

• Development → Staging (promote up)
• Production → Staging (sync down)

The Merge dialog doesn't care about the inheritance hierarchy — it just copies. Pick whichever direction matches your intent.

What merge does not do

• It does not sync servers. Each environment owns its own server list; merging a server set across is intentional friction (you probably don't want your prod server registered twice).
• It does not delete things in the target that don't exist in the source — unless that absence is itself an override (e.g. you explicitly reset a variable in Development, then merge to Production, which clears the Production override too).

Edge cases

• No changes to merge — the dialog still works; nothing happens.
• Two-way diffs — the Changes view always shows the diff relative to the parent in the inheritance chain (Staging vs Production, Development vs Staging). To see Development vs Production directly, you'd compare via two hops or look at the cumulative override state in each tab.

Audit trail

Every merge is recorded in the project's Audit log (left sidebar → Audit log) with who triggered it, which envs, and which categories. Use it to track who promoted what when something breaks.

Next steps

• Environment variables — the thing you'll merge most often
• Install addons from the Browser — addons also propagate via Changes