Use a count for images you may need to roll back to, and an age for builds nobody needs after a short while. A count protects slow moving services. An age keeps busy repositories from filling up. Most registries let you combine both in one policy.
What each approach does
A count rule keeps the newest N images and expires the rest. An age rule expires anything older than a set period. They fail in opposite directions.
| Rule style | Fails when | Good for |
|---|---|---|
| Count | A repository gets many throwaway pushes, so real releases fall out of the window | Release images, base images |
| Age | A service ships rarely, so its only previous version ages out | CI, preview and branch builds |
How three registries describe it
Amazon ECR documents a count type that sorts images from youngest to oldest by push time and expires those beyond the count, and an age type based on days since push. It also documents a pulled time type, covered in our post on last pulled time.
Harbor describes retention as choosing which tags to keep, either a maximum number of tags or a maximum period. Anything not retained is discarded. Counts apply per repository, not across a pool of repositories, so a small repository does not lose images because a busy neighbour is large.
Google Artifact Registry offers delete policies with older than and newer than conditions, and keep policies that retain a number of most recent versions. A keep policy cannot mix conditions and a most recent versions count in the same policy, so you write them as separate policies.
The failure that surprises teams
Mixed repositories. If one repository holds both release tags and CI tags, a count rule counts both. A burst of CI pushes can push the last release out of the window. The fix is to separate by tag prefix, with one rule per class, or to use separate repositories per purpose.
The second surprise is the opposite: an age rule on a repository with a long gap between releases. Imagine a library image released twice a year with a ninety day age rule. After the gap, the previous release is gone and a rollback has nothing to roll back to.
A pairing that works
- A count rule on the release tag prefix, set from your rollback needs.
- An age rule on the CI tag prefix, set to a few days.
- A separate short age rule for untagged images, applied only after you confirm nothing pulls by digest.
Harbor combines multiple rules with OR logic, so an image kept by any rule is kept. ECR evaluates rules together and applies them by priority, with an image matched by at most one rule. Check how your registry resolves overlaps before you stack rules, as covered in how registry retention rules combine.
Test before you trust it
Run the preview or dry run and read the list of what would be removed. A good habit is to also compare against deployed images, since no rule knows what you run.
Safeguard's SBOM and dependency scanning can show what a retained older image still contains, which helps you set an upper age. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the scan and look at how findings differ between a new image and an older one. That difference is what an upper age limit is meant to control.
Quick check
Which is safer for production images, count or age?
A count, because it keeps the last N versions even when a service ships rarely. Add an age rule only for throwaway builds.
Do counts apply across all repositories?
In Harbor, counts apply per repository. Check your own registry, since behaviour differs.
Sources
Last reviewed: 19 October 2026.
