container-registry

Container Registry

A registry is not just storage, it's the trust boundary between "someone built this" and "production is running it." Most registry incidents trace back to one thing: a tag that meant one image yesterday and a different one today, with nothing in the deploy pipeline able to tell.

A tag you can overwrite is not a version, it's a pointer with a rumor attached.

1. Never deploy off a mutable tag

latest, and any tag your CI re-pushes on every build, can change underneath a running deployment with no record of what actually shipped. Tag every build with something immutable — a git SHA, a semantic version, or the content digest itself — and deploy by that identifier. Mutable, human-friendly tags (stable, latest) are fine as a pointer for humans browsing the registry, but the deploy manifest should always reference the immutable tag or digest underneath.

myapp:latest          -> convenience pointer, humans only
myapp:2.4.1            -> immutable, safe to deploy
myapp@sha256:abc123...  -> what actually got pulled, verifiable

Done when: every running deployment can be traced to one specific, unchangeable image digest.

2. Set a retention policy before storage becomes the incident

Registries fill up silently — every CI run pushes a new tag, and without garbage collection the registry grows until a push fails mid-release. Define retention rules explicitly: keep all tags referenced by an active deployment or Helm chart indefinitely, keep the last N builds per branch, and expire untagged/dangling manifests on a schedule. Automate the sweep; a manual cleanup process is a process nobody runs until it's an emergency.

• Never expire a tag or digest currently referenced by a running deployment.
• Cap per-branch history (e.g., last 20 builds) instead of keeping every commit forever.
• Sweep dangling manifests left behind by re-tags and failed pushes on a schedule.

Done when: registry storage growth is bounded by a policy, not by whoever notices it's full.