kubectl rollout undo restores the Deployment's pod template to an earlier revision, and nothing else. It does not revert ConfigMaps, Secrets, database changes or replica counts. It can also bring back an older image that has a known vulnerability, so treat it as a fast stop, not a safe state.
What a revision is
The Kubernetes documentation says a Deployment revision is created if and only if the pod template changes, for example when you update labels or container images. Scaling does not create a revision. When you roll back, only the pod template part is rolled back.
That one sentence explains most surprises. Anything outside the template stays as it is.
| Item | Restored by rollout undo? |
|---|---|
| Container image and tag | Yes |
| Environment variables in the template | Yes |
| Pod template labels | Yes |
| Replica count | No |
| ConfigMap or Secret contents | No |
| Database schema or data | No |
| Service, Ingress or NetworkPolicy objects | No |
The history limit trap
Old revisions live in old ReplicaSets. The documentation says .spec.revisionHistoryLimit defaults to 10, and that setting it to 0 cleans up all history, so that Deployment cannot roll back. Some teams set it to 0 to reduce clutter and discover the cost during an incident. Keep a non-zero value on anything you might need to revert.
The security catch
An undo goes to a previous revision, and previous can mean vulnerable. If the bad release was bad because of a new bug, the older image is fine. If the release was an emergency patch that broke something, undoing it reopens the hole you just closed.
Before you run it, check what you are going back to:
kubectl rollout history deployment/web
kubectl rollout history deployment/web --revision=2
The revision view shows the image. Compare that image against your current advisory list, not your memory of it. You can record intent in the kubernetes.io/change-cause annotation, which the documentation shows is copied to revisions, so the history says why each change happened.
A security rollback routine
- Decide whether you are rolling back for stability or for safety.
- Read the target revision and check its image for known problems.
- Run the undo, then watch the rollout with kubectl rollout status.
- Confirm configuration and data that live outside the template are compatible with the old version.
- Add a note to your incident record, and plan the roll forward with a fixed image.
If a vulnerable older image is the only option, shrink exposure while you fix: restrict network access, scale the affected component down, or pause new traffic at the edge. Document it as a temporary measure.
Rollback is not a patch
A rollback buys time. The durable answer is a new revision with the fix, deployed through the same gates as everything else. If your gate would block the old image, say so in the policy, so an undo does not become a quiet bypass.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests for vulnerable dependencies. It is off by default and every category starts on Manual, so a human decides what ships. That gives you a fixed revision to roll forward to.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is surfaced alongside the finding.
Quick check
Does rollout undo revert my config changes?
Only changes inside the pod template. ConfigMap contents, Secrets and external data are not reverted.
Why does my Deployment say it cannot roll back?
Its revision history may have been cleaned up, for example with revisionHistoryLimit set to 0.
Sources
Last reviewed: 19 October 2026.
