What Is a Container Registry, and How Do Image Pulls Work

A container registry is a storage and distribution service for container images — the packaged, versioned filesystems that Docker and Kubernetes pull and run as containers. When you run docker pull nginx:latest or a Kubernetes pod spec references an image, that image is fetched from a registry, not bundled into your deployment artifact directly. The registry is the thing that actually stores and serves the layers that make up an image.

Images are layers, not one blob

A container image isn’t a single file — it’s a manifest referencing an ordered stack of read-only layers, each one a diff representing filesystem changes from the layer before it. See Docker image layers and caching for how those layers are built. A registry stores each layer as a separate, content-addressed blob, identified by the SHA-256 hash of its contents, plus a manifest that lists which layers make up a given image and in what order.

This content-addressing is what makes registries efficient. If two images share a base layer — say, both are built FROM node:20 — a registry only needs to store that shared layer once, and a client that already has it locally doesn’t need to download it again. Pulling an updated image usually only transfers the layers that actually changed, not the whole image from scratch.

Tags, digests, and what “latest” actually means

An image is referenced by a tag — a human-readable label like nginx:1.27 or myapp:latest — that a registry maps to a specific manifest. Tags are mutable: pushing a new image with the same tag simply repoints that tag to a new manifest, which is why latest is a moving target rather than a fixed version, and why relying on it in production is a common source of “it worked yesterday” surprises.

For a reference that can never silently change, images can also be pulled by digest — the content hash of the manifest itself, written as myapp@sha256:.... A digest always resolves to the exact same bytes, which is why production deployments and CI/CD pipelines that need reproducibility often pin digests rather than tags, especially for anything security-sensitive.

What happens on a pull

When a client pulls an image, the registry interaction follows a consistent sequence: the client requests the manifest for the given tag or digest, the registry returns it, and the client compares the layer hashes listed in the manifest against what it already has cached locally. Only the missing layers are actually downloaded; everything already present — often the base OS layer and common dependency layers shared across many images — is reused. This is why pulling a new version of an image you already have is usually fast: most of the image is unchanged.

Public, private, and self-hosted registries

Public registries host open-source and community images that anyone can pull without authentication. Most organizations also run or subscribe to a private registry for their own application images, gated behind authentication, since those images often contain proprietary code. Cloud providers offer managed private registries, and self-hosted options exist for teams that need images to stay entirely within their own infrastructure — often a requirement alongside other elements of software supply chain security, since a compromised or tampered image is a direct path into production.

Registries and image scanning

Because a registry sits at the boundary between “code someone wrote” and “code that actually runs,” it’s a natural place to enforce policy. Many registries integrate vulnerability scanning that inspects an image’s layers against known CVE databases before allowing a pull, and some support image signing so a cluster can verify an image actually came from a trusted build pipeline rather than being pushed by an unauthorized party. This matters more as more of the deployment pipeline becomes automated — Kubernetes vs Docker covers how a cluster pulls images at scale, and registry-level checks are often the last gate before that happens.

The takeaway

A container registry stores and serves container images as content-addressed layers plus a manifest, letting clients pull only what’s actually changed rather than re-downloading a whole image every time. Tags are mutable pointers that can be repointed by a later push; digests are immutable references to exact content, which is why reproducible deployments pin them instead. Whether public, private, or self-hosted, the registry is also a natural enforcement point for image scanning and signing, since it’s the last stop before an image becomes a running container.