You’ve built a container image — a self-contained bundle of your app and everything it needs. Now what? It’s sitting on your laptop. To get it onto a server, share it with a teammate, or deploy it to a cluster, you need somewhere to store it and hand it out. That somewhere is a container registry — and understanding it is the difference between “containers work by magic on my machine” and “I can actually ship software.”
The cleanest way to think about it: a container registry is “GitHub for container images.” This guide explains what registries are, the vocabulary people trip on, the major ones you’ll meet, and — because a registry is a distribution channel — the security angle that makes this a Secure topic.
Push and Pull: The Two Verbs
The whole thing runs on two actions. You push an image to a registry (upload), and you pull an image from one (download). Just like git push and git clone, but for container images.
You’ve already used a registry without noticing. The first time you run docker run nginx, Docker silently pulls the nginx image from a registry (Docker Hub, by default) before running it. Every containerized deployment on Earth touches a registry: a build pipeline pushes an image, and a production server pulls it.
The Vocabulary People Get Wrong: Registry vs. Repository vs. Image
Three words get used loosely, so let’s pin them down with a library analogy:
- A registry is the whole service — the entire storage-and-distribution server (Docker Hub,
ghcr.io, your company’s private one). The library building. - A repository is one named collection inside that registry, holding all the versions of a single image (the
nginxrepository, thepythonrepository). One book’s shelf, holding every edition. - An image is one specific version inside a repository. A single edition of that book.
So one registry holds many repositories, and one repository holds many versions of one image. Keep those straight and registry documentation stops being confusing.
Tags vs. Digests: The Reproducibility Detail
You point at a specific image in one of two ways, and the difference matters for reliability:
name:tag— human-friendly but mutable.nginx:1.27is readable, but the maintainer can re-push and change what1.27points to later. Andlatestis just a conventional default tag — not a guarantee you’re getting the newest version.name@sha256:...(a digest) — a cryptographic fingerprint of the image’s exact bytes. It’s immutable: the same digest always means the identical image, forever.
Practical rule: use readable tags while developing, but pin production deployments to digests when you need to guarantee you’re running the exact image you tested. This is a small habit that prevents a whole class of “it changed under me” incidents.
Public vs. Private
A public repository lets anyone pull it without logging in — perfect for distributing open-source images to the whole world. A private repository requires authenticated, authorized access — the default for a company’s proprietary images. Most registries offer both.
The Major Registries
Thanks to the shared OCI standard, images are portable across all of these — but you’ll pick one based on where your code and deployments already live:
| Registry | Who runs it | Best fit |
|---|---|---|
| Docker Hub | Docker | The default public registry; official base images (nginx, python, postgres) |
| GitHub Container Registry (GHCR) | GitHub | Teams already on GitHub; tight CI integration (ghcr.io) |
| Amazon ECR | AWS | AWS/EKS workloads, governed by AWS IAM |
| Google Artifact Registry | Google Cloud | GCP/GKE workloads |
| Azure Container Registry (ACR) | Microsoft | Azure/AKS workloads |
| Harbor | CNCF (open source) | Self-hosted / on-premises / air-gapped, with built-in scanning |
Two things worth knowing:
- Docker Hub rate-limits anonymous pulls. Unauthenticated users get a limited number of pulls per few hours (per IP address), and a free logged-in account gets more; paid tiers are unlimited. This regularly trips up CI systems on shared IPs — a common reason teams log in or mirror images. (The exact numbers change, so check Docker’s current usage docs.)
- Google’s older Container Registry (
gcr.io, “GCR”) is shut down (as of 2025) in favor of Artifact Registry. If you see a tutorial pushing togcr.io, it’s out of date.
Security: A Registry Is a Supply-Chain Chokepoint
Because a registry distributes the software everyone runs, it’s a place worth securing — not fearing. The essentials (we go deeper in container security basics):
- Vulnerability scanning. Registries can scan image layers for known security flaws. AWS ECR, Azure (via Microsoft Defender), and the open-source Harbor (with the Trivy scanner) can all scan images — and some can block a vulnerable image from being pulled. Scanning catches known problems; it’s necessary, not sufficient.
- Typosquatting. Because anyone can publish to public Docker Hub, attackers register look-alike names one character off from popular images (
ngingxfornginx,pytohnforpython), hoping for a fat-fingered pull. Researchers have flagged over 1,600 malicious repositories on Docker Hub, many hiding cryptominers. Pull from verified/official publishers. - Secrets leaking in layers. An image layer is essentially a readable archive. A password or API key copied into an image — even one “deleted” in a later step — still lives in the earlier layer, extractable by anyone with the image. Never bake secrets in.
- Signing for authenticity. To prove an image is genuine and untampered, you sign it. Cosign (part of Sigstore) signs images and stores the signature next to them, and can even tie the signature to a build identity rather than a fragile private key. Some registries can enforce “only signed images may be pulled.”
Registries Now Distribute AI Models Too
Here’s the modern twist: registries have become a distribution channel for AI models, not just apps. Model-serving runtimes ship as container images — NVIDIA’s catalog packages models as pullable, signed containers, and frameworks like PyTorch ship as registry images. That’s convenient, but it imports the whole supply-chain problem into AI.
When a developer — or an autonomous coding agent — pulls a model container straight from a public registry, it can bypass an organization’s scanning, versioning, and audit controls, entering production as an unscanned, unversioned artifact. AI images can even carry risks ordinary scanners miss, like model files that execute code when loaded. The fix is the same hygiene as any container: pull models into a private, curated registry, scan and sign them, and pin digests. It’s exactly why the container-registry story and the AI-safety story now overlap.
❓ Frequently Asked Questions
What is a container registry? A container registry is a service that stores and distributes container images — “GitHub for container images.” You push an image to it and pull images from it, which is how a container built on one machine gets shipped to servers, teammates, or a cluster. Docker Hub is the best-known public example.
What’s the difference between a registry and a repository? A registry is the whole service (like Docker Hub). A repository is one named collection inside that registry holding all the versions of a single image (like the nginx repository). An image is one specific version inside a repository. One registry contains many repositories; one repository contains many versions of one image.
What’s the difference between an image tag and a digest? A tag (like nginx:1.27) is a human-friendly, mutable label — the maintainer can change what it points to. A digest (a sha256:... hash) is an immutable fingerprint of the exact image bytes; the same digest always means the identical image. Use tags for readability and pin to digests when you need guaranteed reproducibility.
Is Docker Hub free? Docker Hub has a free tier, but it rate-limits how many images anonymous and free users can pull in a given time window (paid tiers are unlimited). Public repositories are free to host and pull; private repositories and higher pull limits come with paid plans. The exact limits change, so check Docker’s current usage documentation.
Are public container images safe to use? Not automatically. Public registries can host typosquatted look-alike images and images with leaked secrets or vulnerabilities — researchers have found over 1,600 malicious repositories on Docker Hub. Reduce the risk by pulling only from official/verified publishers, scanning images, pinning to digests, and using a private registry for proprietary or sensitive images.
📚 Keep Learning
- Container Security Basics — the fuller security picture for images and registries.
- Docker Images vs. Containers — what actually gets stored in a registry.
- What Is CI/CD? — the pipelines that push images to registries automatically.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Docker Deep Dive
Nigel Poulton · Book · ~$30 on Amazon
The standard, best-selling Docker book — and the natural place to solidify everything around images and registries: building, tagging, pushing, pulling, and the security practices that keep the whole pipeline trustworthy. Clear and hands-on throughout.
The DevOps Handbook (2nd Edition)
Gene Kim, Jez Humble, Patrick Debois & John Willis · Book · ~$25 on Amazon
Registries sit at the heart of the software supply chain, and this is the definitive guide to the practices — automated pipelines, security scanning, and delivery discipline — that make that supply chain fast and safe.