DevOps
Container Registry Retention Rule Cleanup: Fix Policies After Release Changes
Container registry cleanup is often framed as deleting old images, but stale retention rules can be the bigger problem. A policy written for weekly releases may no longer fit daily deploys. A rule that protects stable-* tags may miss digest-pinned rollbacks. A broad keep-last policy may preserve thousands of development images while deleting the one release image support still needs.
This cleanup is for teams whose registry policies have drifted from how software is actually shipped.
Compare policy intent with release reality
Start with the rule, not the image count. Name what each retention rule is supposed to protect: rollback, compliance, customer support, environment promotion, vulnerability investigation, or developer convenience.
| Policy clue | Evidence to review | Risk if ignored |
|---|---|---|
| Tag prefix rules | Current release tags, promotion tags, and branch tags | Important images may not match old prefixes |
| Keep-last count | Deployment frequency and rollback window | Fast releases can push safe images out too quickly |
| Untagged image cleanup | Digest-pinned deployments and SBOM links | Running workloads may rely on untagged digests |
| Exclusions | Support branches and customer-specific builds | Old exclusions may preserve dead product lines |
| Dry-run output | Candidate image list before deletion | Policy may not do what its name suggests |
A useful sample is a policy review table produced by your registry tooling or inventory export: repository, rule name, matched tags, matched digests, last deployed date, and owning release train. Keep the review read-only until owners approve the change.
Evidence checks for retention policies
Look for:
- Deployment manifests that pin image digests rather than tags.
- Release branches still under support.
- Rollback runbooks that name a tag pattern or image age.
- Security tools that link findings, SBOMs, or attestations to old digests.
- Recent rule dry-runs showing which images would be affected.
Do not rush when images support regulated releases, customer-hosted installs, signed artifacts, or long rollback windows. Also slow down when the registry serves multiple products; a rule that fits one service can damage another.
Make policy changes reversible
First, run the rule in report mode if the platform supports it. Second, adjust the policy in a narrow repository before applying it to an organization. Third, keep release images protected by promotion metadata instead of accidental tag names. Fourth, document which support window the policy enforces.
If too many images are retained, prefer a better classification rule over a lower count. Count-based rules are easy to understand but often erase release meaning.
Prevent drift
Tie retention policy review to release process changes. When release cadence, branch support, signing, or deployment promotion changes, update registry retention in the same change set. New repositories should start with policy intent documented in source control so cleanup is not reverse-engineered from whatever survived.
Key takeaways
- Stale retention rules can be as risky as stale images.
- Tags, digests, rollbacks, and support windows must be reviewed together.
- Dry-run output is evidence, not approval.
- Retention policy ownership belongs in the release process.