Skip to content

Rolling Back

Rolling back reverts your app to a previously deployed version. It works by re-deploying a prior Docker image that already exists in the image registry, so your app goes back to the exact code that was running before — without waiting for a new build.

Rollback is an operation, not a single command

There is no mecca rollback command. A rollback is just a deploy that targets an older image tag — mecca app deploy --image-tag <tag> --no-build. This page shows how to do it.

When to Roll Back

Roll back when:

  • You deployed a new version and it has a bug.
  • A deployment completed but the app is not behaving correctly.
  • You need to revert quickly without waiting for a new build.
  • You tried to cancel a deploy and were told it is past the point of no return — see below.

Rolling back is faster than building and deploying a fix because it re-uses an image that already exists in the registry.

A deploy in its final moments cannot be cancelled

mecca queue cancel works right up until the platform swaps traffic onto your new containers. Once that swap commits, cancelling would mean killing the containers that have just gone live — so the cancel is refused and the deploy is allowed to finish:

Not cancelled: 3491b957 is past the point of no return — the swap
has committed and the deploy will finish.
  To go back: mecca app deploy myapp --image-tag <prev> --no-build
  (find <prev> with: mecca build list -a myapp)

That is not an error and there is nothing to retry. Going back from here is a rollback — the steps on this page — not an abort. Cancelling a deploy that is still waiting or building is unaffected and works exactly as before.

Step 1 — Find the tag to roll back to

List the builds for your app:

mecca build list -a myapp -e dev

The Tag column is what you pass to --image-tag. Status tells you which builds are usable: only a succeeded build has an image in the registry, so a failed build is never a rollback target.

To see what is running right now:

mecca app show myapp -e dev

app show prints two version lines, and the difference between them is the whole point:

Running         e06ebcb      ← the image serving traffic right now
Latest build    f0f0510      ← the newest build, which may not be deployed

build list does not mark the live tag

It shows build history, not what is currently serving traffic — so read the Running line from mecca app show and pick the succeeded build before it.

After a rollback, Latest build is NOT what is running

That is exactly when the two lines diverge: a rollback deploys an older image, so Running moves back while Latest build stays on the newest build. If you need to go back a second time, read Running — reading Latest build would have you pick the image you are already on, and the deploy would change nothing.

Pick the tag of the last known-good version (the one running before the bad deploy).

Step 2 — Deploy that tag

Re-deploy the chosen image with --no-build so no new build runs — the existing image is deployed directly:

mecca app deploy myapp --image-tag abc1234 --no-build -e dev

To roll back a specific branch deployment, add -b:

mecca app deploy myapp --image-tag abc1234 --no-build -b feature/payments -e dev

A rollback operates within a branch — it restores a prior image of that branch without affecting other branches.

Because the routing (router rules, routing groups, DNS) already exists from the original deployment, the rollback only swaps the container — typically completing in under 30 seconds.

Step 3 — Confirm

Monitor the rollback deploy with the usual status commands:

mecca queue status <action-id> -e dev
mecca app show myapp -e dev

The deployment shows the older image tag and completed status once the rollback has succeeded.

Rolling back database changes

If the bad deployment included database migrations that must also be reverted, restore the database from a backup taken before that deployment. This is a separate step from the image rollback — there is no single command that does both.

mecca app backups myapp -e dev                 # list available bundles
mecca app restore myapp <bundle-prefix> -e dev # restore DB (+ drives)

Database restore is destructive

Restoring the database replaces its current contents with the backup. Any data written since the backup was taken is lost. See Database Operations.

Back up before deploying

If a deployment includes migrations, take a bundle backup first (mecca app backup myapp -d "pre-release" -e dev) so a clean restore point exists if you need to roll back.

Rollback vs redeploy vs rebuild

Action Command When to use
Roll back mecca app deploy myapp --image-tag <old-tag> --no-build Revert to a known-good previous image, fast
Redeploy current mecca app redeploy myapp Re-run the latest build + deploy from the stored repo URL
Redeploy without rebuilding mecca app redeploy myapp --no-build Restart on the current image
Build + deploy a fix mecca build trigger -g <git-url> -b <branch> Deploy new code that fixes the bug

Automatic rollback

Separately from manual rollback, the deployment agent rolls a deploy back on its own when a new version fails its health checks during the blue/green swap — the old container keeps serving and the new one is discarded, so a failed deploy has zero impact. That automatic safety net needs no command from you; this page is about a deliberate revert of a deployment that completed but turned out to be bad.

Next Steps