How to Roll Back a Bad Deploy

Quick answer
A rollback returns the app to the last known-good version when a deploy breaks something.
Two kinds: redeploy the previous artifact (fast, keeps data), or revert the code (slow, and it re-deploys old code with new data).
Decide and rehearse the rollback before you need it — in an incident, you will not want to think.

What is the fastest way to roll back?

Redeploy the previous version’s artifact — the exact image, bundle, or build from the last good deploy. Platforms make this a button (Render, Railway, Fly.io keep your deploy history); self-hosted, it’s pointing the pipeline at the previous tag. This is fast because the artifact already exists — no rebuild. It restores the old code while the database keeps whatever the new code already wrote, which is usually the behavior you want: the app works, and any schema or data changes from the bad deploy are either forward-compatible or handled separately.

# Self-hosted: redeploy the previous tag
# The artifact exists — this is seconds, not a rebuild
git tag -l "v*" --sort=-v:refname | head -3   # find the last good tag
docker build -t app:v1.4.2 . --build-arg VERSION=v1.4.2
docker compose up -d --no-deps app            # point at the old image

When should I revert the code instead?

Revert the code (git revert or a new commit removing the change) when the rollback needs to become permanent and include other changes that landed on top of the bad one. This is slower — it rebuilds and redeploys — and it’s a different action from a rollback: reverting writes new history that says ‘this change was wrong’. Use artifact rollback for speed during the incident, and decide separately whether the fix is a revert or a repair.

What does a rehearsed rollback look like?

A one-command rollback with a known outcome. Rehearse it on staging: deploy a deliberately broken version, run the rollback, and confirm the app returns to serving healthy traffic within your target time. Also decide in advance what ‘roll back now’ means for your database: if the bad deploy ran migrations, does the rollback need a schema fix first? The rehearsal is what converts ‘we’ll figure it out’ into a measured, calm procedure.

Where this bites vibecoders
The vibecoder’s first real incident is usually a bad deploy — and without a rollback plan, the response is frantic searching for the old version while users see errors. The AI assistant that set up the pipeline never added a rollback button or a rehearsed procedure. The 30-minute investment — artifact-based rollback, documented, rehearsed once — is the difference between ‘60-second fix’ and ‘hour-long scramble’.

Where AI coding assistants get this wrong

No rollback path in the pipeline, so the only recovery is fixing forward under pressure.
Suggesting git revert for the incident rollback, which rebuilds and redeploys instead of restoring quickly.
Rolling back code without accounting for migrations the bad deploy already ran.
Never rehearsing, so the first rollback attempt is a novel operation in the middle of an incident.

Checklist

Keep deploy history and make the previous artifact one click/command away.
Prefer artifact rollback for speed; treat code revert as a separate, deliberate step.
Document whether the rollback needs database migration handling.
Rehearse the rollback on staging until it’s a one-command routine.

FAQ

What is the difference between rollback and revert?

Rollback returns the running app to a previous version, usually by redeploying its artifact — fast, no rebuild. Revert creates a new commit that undoes the bad change and then deploys that — slower, and it’s a permanent statement about the code, not a restore of the old state.

Can I roll back if the bad deploy changed the database?

Yes, but plan it: the app can go back to old code immediately while the schema stays new (old code usually tolerates added columns). If the migration was destructive or the schema isn’t backward-compatible, the rollback includes a schema step — which is exactly why you rehearse the combination before an incident.