Container Registry

Building an image on one machine does not automatically make it deployable elsewhere. Copying tar files around by hand does not scale once versions accumulate, multiple servers consume them, and rollback matters. Without a central place to store and tag images, container portability breaks down at the delivery stage.

Once containers became a team-scale delivery unit, keeping images on the machine that built them was no longer enough. CI/CD only works cleanly when build outputs are pushed to a shared place and each environment can pull the same tagged artifact. As access control, regional replication, and security scanning requirements grew, the registry became more than storage. It became the infrastructure layer between build and execution.

The basic registry structure is a repository plus tags or digests. When you push, Docker uploads only the layers that are not already present. When you pull, it downloads only the missing layers. That layer-aware behavior is what keeps storage and transfer efficient across many related images.

A registry and a source code repository both manage versions, but they manage different things. Source control stores changing text and history. A registry stores already-built image artifacts. Public and private registries also differ meaningfully: public storage is convenient for open distribution, while private storage better fits internal services and access control needs.

In CI/CD, the registry is the handoff point between build and deploy. Pipelines build images, tag them, and push them. Deployment systems then pull those tags into staging or production. In operations, tag strategy matters more than many teams expect: relying only on `latest` hides which code is really running, while semantic versions or commit-based tags preserve traceability.