Rebuild the image and redeploy it. Packages upgraded by hand inside a running container disappear when the container is replaced, and nothing records what changed. Docker's guidance is to rebuild images regularly with updated dependencies, using the pull flag to fetch a newer base image.
Why in place patching fails for containers
A container is meant to be disposable. When you exec into one and run an upgrade, three things go wrong.
- The change lives in that one container's writable layer. The next deploy, restart on a new node or scale out event starts from the old image again.
- There is no review, no build log and no scan result tied to the change.
- Running copies drift apart. One has the fix, others do not.
Docker's best practices page treats images as snapshots, and advises rebuilding regularly. That framing is the answer to the question: the image is the unit you patch.
The rebuild path, step by step
- Update the base. Build with the pull flag so the build fetches a newer base image instead of reusing a cached one. Use the no cache flag when you need every step to rerun, for example after a security advisory.
- Keep apt update and install in the same RUN instruction, so stale package lists do not undo the point of rebuilding. See how should you run apt-get in a Dockerfile.
- Scan the new image before it ships.
- Deploy through your normal pipeline, so every instance changes together.
- Keep the old image digest for rollback, as in rollback plan for an emergency patch.
When a hot fix in a running container is reasonable
Rarely, and only as a stopgap: a live incident where you need to test whether a package update stops an attack while the rebuild runs. If you do it, treat the container as contaminated, note exactly what you changed, and replace it with a rebuilt image as soon as possible.
Pinned digests change the rule slightly
If you pin the base image digest, a rebuild produces the same OS layer. Docker notes that pinning means you opt out of automated security fixes, so you need an update process for the digest. Bots can do this, with review. See should a bot update your container base image.
Rebuild cadence
| Trigger | Action |
|---|---|
| Scheduled | Rebuild all services on a fixed cadence, such as weekly |
| Advisory against a package you ship | Rebuild affected images now |
| Base image update | Roll through services in waves, per rolling out a patched base image |
| Base image reaches end of life | Change the base, not just the tag |
Try it yourself
Click through the image scan and think about what you would change in the Dockerfile to remove each OS package finding.
Click through it at your own pace, or open it full screen.
Quick check
Does apt upgrade inside a container survive a restart?
Not if the container is replaced from the image. The change exists only in that container's writable layer.
How do I make sure a rebuild gets a newer base?
Docker documents the pull flag to fetch a newer base image, and the no cache flag to rerun build steps.
Safeguard scans container images and can raise fix pull requests for dependencies, off by default and approved by you. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
