Rebuild images on a regular schedule and whenever a relevant fix lands, not only when your code changes. An image is a snapshot, so the packages inside age while the image sits in a registry. Use the pull option to refresh the base image and the no-cache option when cached layers could hold stale content.
Why age matters
Your application code may not change for weeks. The operating system packages, runtime and libraries inside the image still collect newly disclosed flaws. A running container does not update itself. Until you rebuild and redeploy, you run what was built.
The Docker build guidance says to rebuild your images regularly with updated dependencies. That one line is the core of the practice.
What pull and no-cache do
The build documentation describes both flags.
- Pull. Forces the builder to check for and download a newer version of the base image, instead of using the copy already on the machine.
- No-cache. Disables the build cache, forcing every layer to be rebuilt from scratch.
- Both together give a fully fresh build.
Why you might need them: cached layers are reused when the instruction text has not changed. A line that installs packages looks the same next month, so the builder may reuse last month's result, along with last month's package versions. The guidance also says to run the package index update and the install in the same RUN instruction, so a cached index layer does not leave the install working from stale lists.
Choosing a cadence
There is no single right number. Consider these inputs.
- Exposure. Internet-facing services deserve faster rebuilds than internal batch jobs.
- Base image update rhythm. Rebuilding more often than your base is updated gains little.
- Test confidence. Fast rebuilds need tests you trust.
- Advisory feeds. Trigger an extra rebuild when a high-severity issue affects something in the image.
A common setup is a scheduled weekly rebuild with a fresh pull, plus event-driven rebuilds for urgent fixes. Pick a cadence you can keep, and measure how old your running images are.
The pinning tension
If you pin the base image by digest, which the build guidance recommends for supply chain integrity, you also stop receiving base updates automatically. The guidance says to use an update tool that proposes pin changes through reviewed pull requests, so fixes arrive deliberately. Pinning and regular rebuilds work together if something bumps the pin.
Rebuild is not the same as redeploy
A new image in the registry changes nothing until workloads use it. Track the gap between "image rebuilt" and "image running." In Kubernetes, remember how pull policy and tags interact. See imagePullPolicy defaults.
Watch out for these
- A rebuild can pull in a breaking change. Tests and staged rollouts catch that.
- No-cache builds are slower, so reserve them for scheduled runs.
- Rebuilding does not fix a flaw with no upstream patch. Other controls apply then.
- Old tags remain in the registry. Remove images you no longer deploy.
A short routine
- Schedule a weekly build with a fresh pull.
- Add a trigger from your advisory source for urgent cases.
- Record each image's build date.
- Alert when a running image passes your age limit.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning plus continuous monitoring help you see which deployed images are affected when a new advisory appears. Try a free scan.
Quick check
Should every build use no-cache?
Not usually. It is slow. Use it on scheduled rebuilds or when you suspect a stale layer.
Is rebuilding weekly enough?
It depends on exposure and how fast fixes reach you. Add event-driven rebuilds for serious issues.
Sources
Last reviewed: 19 October 2026.
