Pull request and branch images can usually expire within days of the last push, or when the pull request closes. Put them under a dedicated tag prefix, expire that prefix by age, and never deploy them to production. Release images follow a different, longer rule.
Why they pile up
Every pushed commit can produce an image. A busy repository makes dozens a day, and nearly all are never deployed. Azure's documentation says as much: in an automated build and test scenario a registry can quickly fill with images that might never be deployed, and they can be purged shortly after the build and test pass completes.
Separate by prefix
The key is that a rule can only target what it can recognise. Give ephemeral images a prefix such as pr- or branch-, and release images a different one. Then one age rule covers the first class and a count rule covers the second.
Google Artifact Registry supports tag prefixes in delete policies, with a tag state set to tagged. ECR supports tag prefix and tag pattern lists. Harbor supports tag filters with wildcards. All three can express "expire pr- tags after N days."
Choosing the age
| Signal | Age to consider |
|---|---|
| Review usually completes within a day or two | A few days after last push |
| Slow review or long lived branches | A week or two, or delete when the branch closes |
| Preview environments that run the image | Match the environment's lifetime, not shorter |
Do not set the age shorter than your longest running preview environment. A deleted image under a running preview fails on restart, the same failure as in production.
Delete on close, expire as backup
The cleanest design deletes the tag when the pull request closes, using a pipeline step, and keeps the age rule as a backstop for branches nobody closes. The backstop catches the leftovers.
Keep them out of production
Short lived tags are not meant for deployment. Enforce that with an admission policy or deployment gate that allows only release prefixed or digest pinned images in production. See how should you tag release container images and scan once and promote the same image digest.
Scanning throwaway images
You do not need to hold throwaway images to the same standard as releases, but scanning them in the pull request catches problems earlier and is cheap. Gate the pull request on the result and let the image expire afterward.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the pull request gate and notice that the check runs before merge, while the image itself is disposable.
Quick check
Is a one day expiry too short?
It can be if reviews take longer or preview environments run the image. Match the longest real use.
Can throwaway tags ever be promoted?
Better to rebuild or promote by digest to a release tag after checks, so a release never depends on a tag that expires.
Sources
- Delete container images in Azure Container Registry
- Artifact Registry cleanup policies
- Amazon ECR lifecycle policies
Last reviewed: 19 October 2026.
