What is a Docker registry and how do you use it?

Question

Accepted Answer

A **Docker registry** is a storage and distribution system for Docker **images** — you **push** images to it and **pull** them from it. **Docker Hub** is the default public registry; organizations often use private registries. Registries are how images are shared and deployed.

## What a registry does

```text
A REGISTRY stores and distributes Docker images:
  → PUSH an image to the registry (upload/publish it)
  → PULL an image from the registry (download it to run)
→ This is how images move between machines: build once, push, pull anywhere
  (CI builds an image → pushes to a registry → production pulls and runs it)
```

## Using Docker Hub (the default public registry)

```bash
# pull a public image (implicitly from Docker Hub)
docker pull nginx:latest
docker pull postgres:16

# push your own image
docker login                          # authenticate
docker tag myapp:1.0 username/myapp:1.0   # tag with your registry namespace
docker push username/myapp:1.0        # upload to Docker Hub
```

**Docker Hub** is the default registry — `docker pull nginx` fetches from it. To publish your own images, you log in, tag them with your namespace, and push.

## Private and cloud registries

```text
Organizations use PRIVATE registries (images not public):
  → cloud provider registries: AWS ECR, Google GCR/Artifact Registry, Azure ACR
  → GitHub Container Registry, GitLab Registry, self-hosted Harbor, etc.
→ Used to store proprietary images securely; integrated with CI/CD and deployment.
```

## Tags and versioning

```text
→ Images are tagged: name:tag (e.g. myapp:1.0, myapp:latest, myapp:abc123)
→ Use specific version tags (myapp:1.2.3) in production, NOT just "latest"
  ("latest" is mutable/ambiguous → unpredictable deployments)
```

## Why it matters

Understanding Docker registries is important because they're how Docker images are **shared and deployed**, a fundamental part of the Docker workflow, so it's valuable practical knowledge.

A registry's core function — storing images that you **push** (publish) and **pull** (download) — is essential to how images move between machines and reach production: the typical workflow has CI building an image, pushing it to a registry, and production pulling and running it, making the registry the central hub of image distribution and deployment.

Understanding **Docker Hub** (the default public registry that `docker pull` uses, and where you can publish images by logging in, tagging with your namespace, and pushing) is foundational.

Knowing about **private and cloud registries** (AWS ECR, Google Artifact Registry, Azure ACR, GitHub Container Registry, etc.) is important for real organizations, which store proprietary images securely and integrate registries with their CI/CD and deployment pipelines.

Understanding **tags and versioning** is practically valuable — especially the best practice of using **specific version tags** (`myapp:1.2.3`) rather than `latest` in production (since `latest` is mutable and ambiguous, causing unpredictable deployments), a common real-world consideration.

Since sharing and deploying images is a fundamental part of using Docker (images must be distributed to run anywhere), and since registries (Docker Hub, private/cloud registries) are the mechanism for this — central to CI/CD and deployment workflows — understanding Docker registries, pushing/pulling, and tagging is valuable, frequently-relevant knowledge for the complete Docker workflow, necessary for distributing and deploying containerized applications in any real setting.