✦ For everyone, free.

Practical knowledge for real and everyday life

Home

3.1.3.4 Image Rollback Support

A focused guide to Image Rollback Support, connecting core concepts with practical Docker and container operations.

Image rollback support is the capability, enabled directly by image immutability and versioning, to revert a running deployment to a previously deployed image version quickly and reliably, without needing to rebuild or reconstruct that earlier version from source.

Rollback as Simply Running an Earlier Tag

Because every released version remains intact and available under its own tag or digest, rolling back means starting a container from that earlier reference rather than performing any kind of reconstruction.

docker run -d --name myapp registry.example.com/myapp:2.2.9

This produces exactly the container that would have resulted from deploying version 2.2.9 originally, since the image itself has not changed in the time since.

Rollback in an Orchestrated Environment

Orchestrators typically provide a dedicated rollback operation that reverts a running service to its previously deployed image, without requiring the operator to remember or look up which tag was previously active.

docker service rollback myapp
kubectl rollout undo deployment/myapp

Both of these commands rely on the orchestrator having recorded which image was deployed previously, reverting to it directly.

Why Fast Rollback Matters During Incidents

Because rollback does not require rebuilding anything, it can be performed quickly during an active incident, directly limiting how long a problematic deployment affects users before being reverted.

docker service update --image registry.example.com/myapp:2.2.9 myapp
Rollback Depends on Disciplined Versioning

Rollback support is only as reliable as the versioning discipline behind it — if a tag like latest was the only reference used for deployment, there may be no clear, unambiguous "previous version" to roll back to, which is one of the practical reasons specific, stable version tags are preferred for production deployments.

docker run -d registry.example.com/myapp@sha256:abc123...

Deploying and tracking by digest provides the most unambiguous possible basis for rollback, since a digest can never refer to anything other than the exact content it was computed from.

Why Rollback Support Matters

Reliable rollback support fundamentally changes the risk calculus of deploying frequently — when reverting a bad deployment is fast and certain to restore exactly the previous working state, teams can ship more often with less fear of a deployment going wrong.