Publishing, versions, and rollback

How configuration versions work, how to publish safely, and how to roll back fast when a change goes wrong.

Goal

Publish configuration changes with confidence, monitor the rollout, and roll back in seconds when needed.

Versions, not edits

ShieldGate never mutates live data-plane state directly. Every publish creates a new numbered version of the configuration snapshot. Nodes pull the version and report what they are running. This gives you three superpowers:

You always know exactly what each node runs.
A bad change is undone by publishing the previous version, not by remembering what you edited.
Draft changes accumulate safely — nothing reaches the data plane until you publish.

The publish flow

Make your edits (they are stored, but not live).
Review pending changes.
Publish — the API creates version N+1 and notifies nodes over Redis.
Watch apply status per node: version applied, timestamp, and any error.

Rolling back

Open the version list, pick the last known-good version, and roll back. The rollback itself is a new publish (version N+2 with old content), so your history stays linear and auditable.

Verify

After publishing, every node's apply status shows the new version within seconds.
After a rollback, behavior returns to the previous state and the version list shows the rollback entry.

Pitfalls

Publishing many unrelated edits at once makes rollback all-or-nothing. Publish in small, coherent batches.
A node that keeps reporting an old version usually lost Redis connectivity — check the node before suspecting the config.