Container Registries and Tagging Strategies

A container registry is a storage and distribution service for Docker images, acting as the handoff point between the build stage of a pipeline and every downstream consumer — deployment jobs, other teams, orchestration platforms like Kubernetes. Popular registries include Docker Hub, GitHub Container Registry (GHCR), Amazon ECR, Google Artifact Registry, and self-hosted options like Harbor. Choosing a registry involves considerations of access control, geographic proximity to deployment targets, cost, vulnerability scanning integration, and how tightly it integrates with your CI platform's authentication model. But the registry itself is only half the story — how images are tagged determines whether a team can reliably answer 'which exact image is running in production right now, and how do I roll back to the previous one?'

The 'latest' tag is a mutable pointer, not a version — pushing a new image to the same tag overwrites what 'latest' refers to, meaning two different deployments referencing 'myapp:latest' at different times could run entirely different code with no record of what changed. This makes rollbacks unreliable, debugging painful, and reproducibility impossible, since you cannot pull the exact image that was running last Tuesday once 'latest' has moved on. Production pipelines should almost always deploy using immutable, uniquely identifying tags rather than 'latest', reserving 'latest' at most as a convenience alias for local development.

The most robust tagging strategy uses the git commit SHA (or a shortened form of it) as the primary tag, since a SHA uniquely and permanently identifies the exact source code that produced the image — there can never be ambiguity about what 'app:a3f9c21' contains. Many teams layer additional, more human-readable tags alongside the SHA: semantic version tags (v2.4.1) for released software, branch-based tags (main, staging) that do move but are understood to be mutable pointers used only for non-production environments, and date-based tags for audit trails. A common pattern pushes the same image under multiple tags simultaneously — the immutable SHA and one or more mutable convenience aliases — so different consumers can reference the level of stability they need.

Because every pipeline run can push a new uniquely tagged image, registries accumulate storage costs and clutter quickly. Most registries support retention policies that automatically expire untagged or old images after a configurable period, while explicitly protecting tags matching patterns like v* or images referenced by an active deployment. Designing this policy is a balance: too aggressive and you lose the ability to roll back to an older known-good build; too lax and storage costs and image sprawl grow unchecked.