Rolling back a deploy: what goes back to the old version and what stays changed

A rollback redeploys; it does not rewind

After a bad deploy the instinct is to go back. Going back means serving an earlier build of the code. It does not change what the bad release already did. Hosted platforms make this explicit. Vercel's instant rollback, for example, points production domains at an earlier deployment without rebuilding it, and its confirmation step reminds you that external APIs, databases and content systems may behave differently from when the earlier deployment was current. The earlier code then runs against whatever the new code left behind.

Four things that do not come back

Settings: on that platform, environment variables are not changed by a rollback, so a value you edited for the new version stays edited, and the earlier build may read it.

Data: a migration that renamed or removed a column, or rows the new code wrote in a new shape, are still there. The earlier release has to be able to read them. A common way to keep that possible is to make structural changes in two steps, adding the new shape first and removing the old one in a later release, but that is a design choice for your team, not something a pipeline setting provides.

Work in flight: scheduled jobs revert to the rolled-back deployment's state on that platform, but queued messages, sent emails and charges that already happened do not.

The platform's own limits: only deployments that served production before are eligible, and the Hobby plan can return only to the previous deployment, so the release you want may not be reachable.

• Settings and environment values
• Database structure and data written by the new code
• Queued, sent or charged work
• Which earlier releases are still available

Name what you would go back to

Before rehearsing anything, write down three facts. What is an earlier release in your system: a tagged image, a stored build artefact or a platform deployment? Where are the last several kept, and for how long? And how would you know the earlier version is the one serving traffic, for example a version string on a health endpoint? If you cannot answer the first, a rollback has nothing to restore, and retaining releases comes first.

Rehearse on a copy, with a person approving

Rehearse on a staging environment that is separate from production and holds only test data. Use the same deploy path as a forward deploy, with the same health check, and record the time from start to healthy. Where the pipeline runs on GitHub, an environment with required reviewers makes each deploying run wait for a named person. Then deploy the current release again to prove you can come forward. A rehearsal shows the code path works. It does not prove production will behave identically, and nobody should read it as a recovery-time promise.

How the paid outcome is accepted

The fixed job adds one rollback action to one service's pipeline and rehearses it on staging. It is accepted when the action deploys a named earlier release to staging using the same steps as a forward deploy, the health check passes and staging reports the earlier version, a forward deploy afterwards also succeeds with both times recorded, and a written list says what a rollback does and does not restore and you confirm it is accurate for your system. We never run anything on production. It starts at £595, untested, and is paid after you sign off.