What is a container registry, and how does Docker Hub fit in?
Quick Answer
A container registry is a service for storing, versioning, and distributing container images — you push images to it and pull them from it, the same way a package registry (npm, PyPI) works for language libraries. Docker Hub is the default, most widely used public registry, hosting both official/verified images (like node, postgres, nginx) and user/organization-published images; private registries (self-hosted, or cloud-provider-managed like ECR/GCR/ACR) exist for images an organization doesn't want publicly accessible.
Detailed Answer
What a registry actually does
A registry is a storage and distribution service specifically for container images — organized by repository (a named collection of related images, usually one application) and tag (a specific version within that repository — see the tags-vs-digests question). Pushing uploads a locally-built image to the registry. Pulling downloads an image from the registry to a local machine — this also happens automatically whenever a container is started from an image that isn't already present locally (see the fundamentals topic's hello-world walkthrough).
docker pull nginx:1.25
docker tag myapp:1.0 myusername/myapp:1.0
docker push myusername/myapp:1.0
Docker Hub — the default public registry
Unless configured otherwise, docker pull/docker push (and an unqualified FROM in a Dockerfile) default to Docker Hub. It hosts several categories of images:
- Official images (
node,postgres,nginx,python, and similar) — curated, actively maintained images for popular software, vetted by Docker and typically the recommended starting point as a base image. - Verified Publisher images — published directly by the software vendor themselves (e.g., a database company publishing their own official image), carrying an extra trust signal beyond a purely community-contributed image.
- Community/user images — published by anyone with a Docker Hub account, with no particular vetting — worth treating with the same caution you'd apply to installing an unfamiliar package from a public code registry with no reputation signal.
Why unqualified image names default to Docker Hub
FROM node:20 # implicitly: docker.io/library/node:20 (Docker Hub, official image)
FROM myorg/myapp:1.0 # implicitly: docker.io/myorg/myapp:1.0 (Docker Hub, user/org namespace)
An image reference with no registry hostname prefix is resolved against Docker Hub by default. This is purely a configured default in the Docker daemon, not a hardcoded requirement. Referencing a different registry explicitly just requires including its hostname in the image reference (see the private-registry question).
Rate limiting — a real, practical Docker Hub consideration
Docker Hub imposes pull rate limits for anonymous and free-tier authenticated accounts — a detail that occasionally surfaces as mysterious ImagePullBackOff-style failures (see the Kubernetes stack's equivalent question) in CI pipelines or clusters making many pulls from many nodes in a short window. Authenticating with a Docker Hub account (even a free one) raises these limits substantially over anonymous, unauthenticated pulls, and is a common, simple mitigation for pipelines hitting this limit.
Why organizations often move to a private or alternative registry
Public registries are the right default for genuinely public, open-source images. But proprietary application images generally shouldn't be pushed to a public registry at all. This is both for confidentiality — source or build details potentially inferable from image layers — and to avoid depending on a third-party public service's availability or rate limits for critical internal deployments. This is exactly the motivation covered in the private-registry question.