Docker Hub vs Docker Registry
You’ve been using a registry this whole time without naming it. Every plain alpine, nginx, or alpine:3.19 you’ve pulled came from somewhere specific — and that somewhere has a name: Docker Hub. It’s easy to assume “registry” and “Docker Hub” are the same thing, since Hub is the default and you never had to configure anything to use it. They’re not the same thing, and the difference matters the moment you’re not just pulling public base images anymore.
Docker Hub Is a Registry, Not “The” Registry
Docker Hub is Docker’s own public registry, and it’s the one your engine talks to by default whenever an image name doesn’t specify otherwise. When you ran docker image pull alpine, what actually happened under the hood was closer to:
docker image pull docker.io/library/alpinedocker.io is Docker Hub’s registry address, filled in silently because you didn’t provide one. That’s the whole trick — image names are really <registry>/<repository>:<tag>, and Docker just assumes Docker Hub when the registry part is missing.
Once you write out a different registry address explicitly, the same pull command works against a completely different server:
docker image pull ghcr.io/some-org/some-image:latestSame command, same mechanics you learned last section — manifest first, then only the missing layers — just pointed at GitHub’s registry (GHCR) instead of Docker Hub. The registry concept doesn’t change; only the address does.
Public vs Private Registries
Every registry, Docker Hub included, falls into one of two access models:
- Public registries let anyone pull images without credentials (though pushing usually still requires an account). Docker Hub’s free tier, GHCR, and Quay.io all operate this way for public repositories.
- Private registries require authentication to pull, push, or both. Access is restricted to people or systems with credentials — useful the moment an image contains anything proprietary, or you simply don’t want it discoverable by the public.
Docker Hub itself supports both: you can host public repositories for free, or pay for private ones. The public/private distinction is a property of the repository, not something exclusive to any one registry provider.
| Scope | Docker Hub | Other public registries (GHCR, Quay) | Private / self-hosted registry |
|---|---|---|---|
| Default for unqualified image names | Yes | No — must specify address | No — must specify address |
| Anyone can pull (public repos) | Yes | Yes | No — auth required |
| Where it commonly lives | Docker’s own infrastructure | Tied to another platform (GitHub, Red Hat) | Your own infrastructure, or a cloud provider’s registry service |
| Typical reason to use it | Default, huge ecosystem of official images | Already using that platform for other things (e.g. code already on GitHub) | Proprietary images, internal-only distribution, compliance requirements |
Why an Organization Runs Its Own Registry
If Docker Hub is free and already the default, why would anyone bother running a private one? A few recurring reasons:
- The images aren’t meant to be public. Internal application images often contain things you don’t want sitting on a public server at all, regardless of pricing.
- Rate limits. Docker Hub throttles anonymous and free-tier pulls per IP address over a rolling window. A team pulling the same images repeatedly in automated pipelines can hit that ceiling surprisingly fast — self-hosting removes the limit entirely.
- Network locality. A registry running inside the same network as the machines pulling from it is faster and doesn’t depend on internet access at all — relevant for tightly controlled or offline environments.
- Control over retention. A private registry can be configured with its own rules for how long old tags stick around, which Docker Hub’s free tier doesn’t give you much say over.
None of this makes Docker Hub the wrong choice by default — it remains the simplest option, and it’s exactly why it stays the default when you don’t specify otherwise. Private registries solve problems that only show up once you have them.
Note
Cloud providers usually offer their own managed private registries — Amazon’s ECR, Google’s Artifact Registry, Azure’s ACR. Mechanically they’re still just registries speaking the same manifest/layer protocol you learned last section; the “managed” part is about who operates the server and handles authentication, not a different way of storing images.
What’s Next
Right now this is all still conceptual — you know what separates a public registry from a private one and why Docker Hub happens to be the default, but you haven’t pushed anything anywhere yet. That changes soon: once you’ve covered docker container commit, you’ll have an image worth pushing, and Commit and Push will put both pieces together — including standing up and pushing to a registry of your own.