Versions and rollback

Every publish to mcpg.cloud is a numbered config version. How to list history, diff any two versions, and roll a managed gateway back to a known-good one.

Every time you publish a config under a name, mcpg.cloud stores it as a numbered version. That history is your safety net: you can see exactly what changed and revert a bad rollout in one command.

List the history

bash

mcpg cloud versions edge          # published config versions for instance "edge"

Each entry is a config artifact the platform kept when you published — the source of truth for what that instance was running at that point.

Diff two versions

Before rolling forward or back, see what actually changed between versions:

bash

mcpg cloud diff edge --from 4 --to 5

Roll back

Revert the instance to an earlier version:

bash

mcpg cloud rollback edge --to 4

Pass the deploy params. A rollback restores the config of the target version, but deploy parameters (--replicas, --size, --region) do not yet default from that version. If the instance has drifted from the defaults, pass those flags on the rollback command so the shape matches what you intend.

How versioning relates to publishing

Rollback and publish are two sides of the same store: a rollback --to N re-deploys the config from version N, and any subsequent publish records a new version on top. There is no separate "save" step — publishing is versioning.

Where to go next

Publish a config — the publish loop that creates versions.
Day-2 operations and upgrades — the self-hosted equivalent of version control + rollout.
mcpg cloud reference — every command and flag.