There is no universal number. Keep as many release images as your rollback and support commitments need, usually a handful of recent versions per service, and keep far fewer for CI and pull request builds. Decide by purpose, not by a single count applied to every repository.
Start from what each image is for
A registry holds images with very different lives. Treating them the same either deletes things you need or hoards things you do not.
| Image type | Typical purpose | Sensible retention basis |
|---|---|---|
| Release builds | Deployed to production | A count of recent versions plus any supported older lines |
| Pre release or staging builds | Testing a candidate | A short age window |
| Pull request and branch builds | Review and test | A very short age window |
| Base images you publish | Used by other teams | Keep versions that dependants still reference |
| Cached upstream images | Speed and resilience | Follow the upstream source and your refresh policy |
Count or age for releases
For release images, a count is usually safer than an age. If a service ships twice a year, an age rule of ninety days could remove its only previous version. A count keeps the last N regardless of how slowly the service moves. Amazon ECR supports both styles: a count type that expires images beyond a number, sorted by push time, and a type based on days since push. Harbor lets you retain by a maximum number of tags or by a period.
Pick N from your rollback story. If your practice is to roll back one or two versions, keeping five gives margin. If regulated customers can pin older versions, keep those lines explicitly instead of enlarging N for everything.
Age for everything throwaway
CI images, preview builds and branch images rarely matter after a short while. An age rule fits. Our post on TTL for pull request and branch image tags shows how to isolate them with a prefix so the rule never touches releases.
Do not forget the security angle
Every retained image is something that can still be pulled and can carry known flaws. The goal is not a minimum count, it is a count you can justify and patch against. Our guide on how old is too old for a container image helps you set an upper bound on age for anything still deployed.
A worked example
Suppose a payments service ships weekly and keeps one supported older line for a long running customer.
- A rule keeps the last eight tags with the
release-prefix. - A second rule keeps all tags with the
lts-prefix. - A third rule expires anything with the
ci-prefix after a few days. - Untagged images are expired after a short period, after checking nothing pulls by digest.
Each rule has a reason you can write on one line, which makes review easy.
Review the number
Revisit the count when release cadence changes. A team that moves from monthly to daily releases will find the same count covers far less calendar time.
Safeguard's free scan at gold.safeguard.sh/scan can show what retained dependencies carry, which helps you judge whether older retained versions are worth keeping.
Quick check
Is a higher count always safer?
No. It protects rollback but keeps more images that can be pulled with known flaws. Set the count from your rollback and support needs.
Can I use one rule for the whole registry?
You can, but separate rules by purpose are easier to reason about and less likely to delete something you need.
Sources
Last reviewed: 19 October 2026.
