Put the image class first in the tag, then the version, then a build identifier, for example release-1.4.2, pr-482-a1b2c3d and ci-20261019-77. A class prefix lets one rule target one kind of image, which is what every major registry retention feature is built to match.
Why the tag matters
Retention rules cannot read your intent. They read tags, ages, counts and, in some cases, pull times. A rule can only protect or expire what it can recognise. If release and throwaway images share a tag shape, you cannot write a rule that treats them differently.
All three registries reviewed here match on tag text. Amazon ECR supports tag prefix lists and tag pattern lists with wildcards, limited to four wildcards per string. Google Artifact Registry supports tag prefixes and version prefixes. Harbor supports tag filters with wildcards, including matching or excluding names.
The scheme
| Class | Example tag | Rule |
|---|---|---|
| Release | release-1.4.2 | Keep the last N, never expire by age |
| Long term support | lts-1.2.9 | Keep until the line ends |
| Release candidate | rc-1.5.0-3 | Expire after a short age |
| Pull request | pr-482-a1b2c3d | Expire after a few days |
| CI build | ci-20261019-77 | Expire after a few days |
The prefix is the handle, the version identifies the release, and the suffix ties the image to a commit or build.
Rules that avoid common mistakes
- Do not rely on latest. A mutable tag is not a version, and a rule cannot reason about it. See a tag is not a version.
- Avoid tags that match several classes. An image tagged both
release-1.4.2andci-77is kept if either rule keeps it in Harbor, and is matched by only one rule in ECR. Be deliberate about which tags an image carries. - Keep prefixes distinct. In ECR the set of rules selecting a storage class must use a unique set of prefixes, so avoid nested prefixes such as
relandrelease. - Use semantic versions for releases. Sorting by push time is fine for counts, but readable versions help humans.
Write the rules before the pipeline
Define the classes, then make the pipeline emit tags that match. Publish the scheme in your contributing guide so every team follows it. Then automate a check that flags tags outside the scheme.
Tags and digests together
Tags are for people and rules. Digests are for deployment and verification. Deploy by digest, record the digest at release, and use tags to organise cleanup. See how should you tag release container images and which image tags in a registry should you scan.
Migrating an existing repository
You rarely start clean. For an existing repository, add the new tags alongside the old ones going forward, write rules for the new prefixes, and leave old tags alone until they age out under a conservative rule. Do not retag history in bulk, since that makes digests and tags harder to reconcile with past records.
Quick check
Should the class be a prefix or a suffix?
A prefix, since the registries reviewed here support prefix matching directly, and prefixes sort together in listings.
Can one image carry two class tags?
It can, but rule results then depend on your registry's overlap logic. Avoid it unless you have tested the outcome.
Sources
Last reviewed: 19 October 2026.
