Before you allow auto-merge on a service, confirm you can redeploy the previous build quickly and that doing so is safe. Check that old artifacts are kept, the deploy is repeatable, data changes are backward compatible, and someone has practised the rollback this quarter.
Rollback is a capability, not a sentence
Many runbooks say "roll back if needed". That sentence is true only if several things are also true. Auto-merge raises the stakes, because changes can land with no human watching the merge. So test the preconditions first.
The preconditions
| Precondition | Question to answer |
|---|---|
| Previous build exists | Is the last known good artifact still stored and deployable? |
| Deploys are repeatable | Can you redeploy that artifact with one command or button? |
| Config is versioned | Does the old build run with today's configuration? |
| Data compatibility | If the new build wrote data, can the old build read it? |
| Dependencies of dependencies | Does the old build's lockfile still resolve, or did a package get removed? |
| Authority | Does the on-call person have permission to roll back without waiting for approval? |
| Practice | Has someone done it recently, and how long did it take? |
Data is the hard one
Code rolls back easily. Data does not. If the updated dependency changed how records are serialized, written or indexed, the old code may fail on new records. Ask the question before the change: does this update touch storage, serialization, encryption or database drivers? If yes, keep that category on manual approval and plan a staged rollout.
Artifacts and lockfiles
Rebuilding the old version from source is not always the same as redeploying the old artifact. Registry packages can be removed or yanked, and a rebuild may pull different transitive versions if your lockfile is not honoured. Redeploy the stored artifact when you can. Renovate even has a rollback feature for the case where the current version has been removed from a registry: it proposes a downgrade to the next highest release, and it is off by default. That shows registry removal does happen, so do not rely on rebuilding.
Practise it
Run a rollback drill on a harmless change. Time it. Note what surprised people. A fifteen minute drill per service per quarter is a modest cost. The result is a number you can trust, which you can write into the auto-merge register. For the mechanics, see roll back a bad dependency upgrade safely and how rollback differs for OS patches and dependency updates.
If you fail a precondition
Fail one, keep that service on manual approval, and fix the gap. A missing stored artifact is a quick fix. Data compatibility may be a longer project. Either way, you know where you stand, which is the purpose of the check.
Rolling forward is also an option
Sometimes the right response is a new fix, not a revert, especially when the old version has the vulnerability you just closed. Decide in advance who may choose between the two. See roll forward or roll back when artifacts are immutable.
Try it yourself
Open the demo and watch a service's state change over time. After a rollback you would use a view like this to confirm the finding and the service are both back to normal.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Is a revert pull request the same as a rollback?
No. A revert changes the code in the repository. A rollback redeploys a previous build. You may need both.
Who should be allowed to roll back?
The on-call owner of the service, without waiting for a separate approval, since delay is the main cost.
Sources
Last reviewed: 19 October 2026.
