Where to Store Docker Images

Introduction

Your container registry is not a file share — it is a link in your software supply chain and a runtime dependency of every deployment. If it's down, you can't scale out or roll back; if it's poorly governed, you're one mutable tag away from not knowing what's running in production. Here is how the registry landscape actually looks in 2026, and the hygiene that matters more than which vendor you pick.

The 2026 Registry Landscape

Cloud Provider Registries: ECR, Artifact Registry, ACR

If your workloads run on AWS, Google Cloud, or Azure, the default answer is the provider's registry: Amazon ECR, Google Artifact Registry (which replaced the retired Container Registry), or Azure Container Registry. You get native IAM for push/pull permissions, private network endpoints so pulls never cross the internet, built-in vulnerability scanning, and cross-region replication. Pulls from within the same region are fast and typically free, which matters at cluster scale — a point that recurs across our cloud computing engagements, where registry egress is a small but recurring line item people forget to design away.

Git-Forge Registries: GHCR and GitLab

GitHub Container Registry and the GitLab Container Registry put images next to the code and the CI that builds them, with authentication piggybacking on the token your pipeline already has. For open-source distribution and for teams whose whole lifecycle lives in the forge, this is the lowest-friction option in 2026.

Docker Hub

Docker Hub remains the largest public catalog and the right place to distribute a public image. As a private enterprise store it has become uncommon — and its anonymous pull rate limits make depending on it directly from CI or production a self-inflicted outage waiting to happen (the fix is a pull-through cache, below).

Self-Hosted: Harbor

Harbor, a CNCF-graduated project, is the standard when data residency, air-gapped environments, or full control demand self-hosting: project-level RBAC, quotas, replication between registries, a proxy cache, and Trivy scanning built in. Quay is the notable alternative. Self-hosting means you now operate a tier-zero service — budget for that honestly.

Registry Hygiene That Actually Matters

1. Make Tags Immutable

Enable tag immutability where the registry supports it (ECR and Harbor do) and deploy by unique version tag or digest — never by a mutable :latest. If a tag can be silently repointed, "what is running in production?" has no reliable answer, and neither does a rollback.

2. Set Retention Policies

CI produces images relentlessly; without lifecycle rules a registry becomes an expensive junk drawer. Expire untagged manifests within days and keep the last N releases per repository — every major registry supports this natively.

3. Sign Images and Verify at Admission

Sign images in CI with cosign (Sigstore — keyless signing against your CI's OIDC identity) or Notation, then enforce verification at the cluster with an admission policy such as Kyverno. A signature that nothing verifies is decoration; the enforcement side is where our SecOps practice spends most of the effort.

4. Scan in CI and in the Registry

Scan with Trivy or Grype in the pipeline before pushing, and keep registry-side scanning on (ECR scanning, Harbor's built-in Trivy) so images built weeks ago get re-flagged when new CVEs land. Scanning is only half the story — the image has to be worth scanning, which starts with the build itself; see our Dockerfile best practices guide.

5. Run a Pull-Through Cache

Mirror upstream registries instead of depending on them live: ECR pull-through cache rules, Artifact Registry remote repositories, or a Harbor proxy project. Your builds and clusters keep working through a Docker Hub outage or rate-limit squeeze, and pulls get faster and cheaper.

6. Push From CI With OIDC, Not Stored Keys

Docker Hub's legacy automated-builds feature is not how images get built in 2026 — CI is. Have GitHub Actions (or your CI of choice) assume a short-lived cloud role via OIDC federation to push to ECR or Artifact Registry. No long-lived registry credentials sitting in CI secrets.

Conclusion

Pick the registry closest to where your workloads run, then spend your energy on the hygiene: immutable tags, retention, signing with verification, layered scanning, and a pull-through cache. That combination — not the vendor logo — is what makes a registry trustworthy.