Container Registries: Where Your Images Live

A Registry Stores Layers, Not Files

A container registry looks like a file server for images. Underneath it is something more interesting: a content addressed store of compressed layers plus small JSON manifests that describe how those layers stack.

That design has practical consequences. Two images sharing a base contribute those layers only once, so a registry holding thirty builds of the same application is far smaller than thirty times one image. It also means a push that appears to hang is usually uploading one enormous layer, not thirty small ones.

The format is standardised by the Open Container Initiative, which is why an image built with Docker can be pulled by containerd, Podman or a Kubernetes node without anyone thinking about it. Registries are interchangeable in the same way.

Reading an Image Reference Properly

A full reference has four parts: registry host, repository path, and then either a tag or a digest.

registry.digitalocean.com/acme/api:1.8.3 names a host, a namespace, a repository and a tag. Leave the host off and the client silently assumes Docker Hub, which is why nginx:latest works without any configuration and why people are surprised when a pull fails behind a restrictive firewall.

Tags are mutable labels. Nothing stops a tag being moved to a different image tomorrow, and latest is simply a conventional default with no special meaning. A digest is different: api@sha256:... refers to exact bytes and cannot be repointed.

The working rule is to tag with something meaningful for humans, usually a version or a commit identifier, and to deploy by digest wherever the tooling allows. That is what makes a redeploy genuinely reproducible instead of probably reproducible.

Where to Put Them

The deciding factor is rarely features, since all of them store and serve images competently. It is proximity and identity. A registry in the same provider as the workload pulls faster, avoids cross network transfer charges, and lets the platform's own identity system authorise the pull instead of a stored password.

Harbor is worth knowing about as the self hosted option. It is a CNCF project offering replication between registries, a proxy cache for upstream images, and policy enforcement, and it is the usual answer when images must never leave a network you control.

How Machines Prove They May Pull

Every managed registry ties access to the surrounding platform's identity system rather than to its own user list. The practical effect is that you exchange a platform credential for a short lived registry token.

On AWS that exchange is explicit: aws ecr get-login-password prints a temporary password that is piped into docker login. Azure wraps it in az acr login, and Google Cloud configures the Docker client to use gcloud as a credential helper. In each case the token expires, which is the point.

Inside Kubernetes, a pull secret provides the credentials, and the better pattern is to let the node's own identity authorise the pull so no secret is stored at all. Where a static credential is unavoidable, treat it with the care described in managing API keys and secrets in cloud projects.

Two rules cover most incidents. Push credentials belong only to the build pipeline. Production nodes need pull access and nothing more, because a compromised node that can push images is a compromised supply chain.

Keeping Images Small and Repositories Tidy

Image size is a deployment speed problem and a cost problem at once. Two techniques do most of the work.

Multi stage builds compile in one stage and copy only the finished artifact into a minimal runtime stage, so compilers and development headers never reach production. Slim or distroless base images take it further by removing the shell and package manager entirely, which shrinks both the download and the attack surface.

Layer order matters too. Put instructions that rarely change, such as dependency installation, before instructions that change on every commit, so the cache survives ordinary work. Copying the whole source tree before installing dependencies discards the cache every single build.

Then deal with accumulation. Every build leaves an image behind, and untagged layers from overwritten tags linger. Managed registries offer lifecycle or retention rules to expire images by age or by count, and configuring one at creation time is far easier than reclaiming space during a storage alarm.

Amazon documents its expiry behaviour in the ECR lifecycle policy documentation, and the general build guidance is collected in Docker's build best practices.

Scanning, Signing and Knowing What You Shipped

A registry is the natural checkpoint for supply chain controls, because every image passes through it exactly once.

Vulnerability scanning compares the packages in each layer against public advisory databases. Most managed registries can scan on push, and open tools such as Trivy or Grype run the same check inside a pipeline. Scan results age, so rescanning existing images on a schedule matters as much as scanning new ones.

Signing addresses a different question: not "is this image safe" but "did we build it". Sigstore's cosign has become the common approach, and cluster admission policies can refuse to run anything without a valid signature.

A software bill of materials records the components inside the image so that when a new advisory lands you can answer whether you are affected by querying rather than by rebuilding everything. Generating one at build time and attaching it to the image keeps the answer next to the artifact.

These controls fit naturally into an automated delivery flow. Where images are the unit of deployment, they also become the unit the reconciliation loop watches, which is the model described in GitOps basics for cloud teams.

Practical Questions

Teams running containers on the same platform as their registry get the smoothest experience, since identity, network and billing all line up. The IBM Cloud account listings describe an account where the built in registry and its IAM model are available, and the AWS versus IBM Cloud comparison looks at how the two organise container tooling. Running the engine itself is covered in running Docker on a cloud server.