Container Registry

TL;DR

• A container registry stores and serves OCI/Docker images; the meaningful differentiators between options are identity integration, availability/rate limits, and operational control, not raw storage capability.
• Docker Hub rate-limits anonymous and free-tier pulls — a real production risk if a scaling event pulls more images than the tier allows.
• Amazon ECR and GHCR integrate registry auth directly into their platform’s native identity (IAM, GitHub tokens) — no separate registry credential to manage or leak.
• Harbor is the self-hosted, vendor-neutral option for multi-cloud, hybrid, or data-residency requirements.
• Image retention policy is required for the same reason as general artifact retention: every uniquely-tagged CI-built image accumulates indefinitely without one.
• Biggest gotcha: depending on Docker Hub’s free tier as the direct source for production pulls at real scale.

Core Concepts

Registry vs. repository terminology

A registry is the service (Docker Hub, ECR, Harbor) that hosts and serves images over the registry HTTP API. A repository is a named collection of image versions within that registry (e.g. myorg/myapp), identified by tags or digests. Multiple repositories live inside one registry; the registry is the server, the repository is the addressable image namespace within it.

Docker Hub

Docker Hub is the original public registry and the default unauthenticated pull source referenced by short image names (nginx resolves to docker.io/library/nginx). The operational fact that matters: anonymous and free-tier authenticated pulls are rate-limited per IP or per account within a rolling window. A production cluster scaling out — many nodes pulling images in a short window — can exceed those limits and turn a routine scaling event into a self-inflicted image-pull failure across the fleet.

Amazon ECR

ECR integrates push/pull authorization directly into AWS IAM. An EKS node’s instance role, or a CI pipeline’s OIDC-assumed role, is granted registry permissions through the same IAM policy mechanism used for every other AWS resource — no separate registry username/password to provision, rotate, or leak. Authentication uses short-lived tokens obtained via aws ecr get-login-password, which are exchanged for Docker registry auth, rather than long-lived static credentials.

GHCR (GitHub Container Registry)

GHCR provides the equivalent integration for GitHub-centric workflows: images published from Actions workflows authenticate using the automatically-provisioned GITHUB_TOKEN (or a PAT with write:packages scope), and package visibility/permissions can be tied to the source repository’s own access control. This removes the need for a separately managed registry credential inside CI.

Harbor

Harbor is a self-hosted, open-source registry providing vendor-neutral control: useful for multi-cloud or hybrid environments where a single cloud-native registry doesn’t fit every environment, for data residency requirements dictating exactly where image content and metadata physically reside, and for teams wanting a consistent feature set (vulnerability scanning, image replication between instances, project-based RBAC) independent of any one cloud provider’s implementation, feature roadmap, and pricing.

Retention and cleanup

Every CI build that pushes a uniquely-tagged image (per commit, per pull request) accumulates in the registry indefinitely without an explicit policy, producing an unbounded and unbudgeted storage cost. The fix mirrors general artifact retention: retain release/production-tagged images per actual operational or compliance need, and aggressively clean up ephemeral per-commit or per-PR images once they no longer serve a purpose (merged, closed, superseded).

Docker Hub vs Amazon ECR vs GHCR vs Harbor

Command / Configuration Reference

# Docker Hub — pull subject to anonymous/free-tier rate limits
docker pull nginx:latest

# Amazon ECR — authenticate via IAM-issued short-lived token
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <account-id>.dkr.ecr.us-east-1.amazonaws.com
docker push <account-id>.dkr.ecr.us-east-1.amazonaws.com/myapp:latest

# GHCR — authenticate using a GitHub token
echo $GITHUB_TOKEN | docker login ghcr.io -u <username> --password-stdin
docker push ghcr.io/<org>/myapp:latest

# Harbor — self-hosted, project-scoped push
docker login harbor.example.com
docker push harbor.example.com/myproject/myapp:latest

Common Pitfalls

• Pitfall: Production image pulls depend directly on Docker Hub’s free/anonymous tier. Why: Rate limits apply per IP/account within a rolling window, and a scaling event can exceed them, causing pull failures across the fleet. Fix: Use a pull-through cache, a cloud-native registry (ECR/GHCR), or a paid Docker Hub tier with adequate limits.
• Pitfall: Managing a separate registry credential alongside existing cloud/platform identity. Why: A standalone registry username/password is an extra secret to provision, rotate, and potentially leak, duplicating what native integration already provides. Fix: Use ECR’s IAM integration or GHCR’s GitHub-token integration instead of a bespoke credential store.
• Pitfall: No image retention policy, letting per-commit/per-PR tags accumulate indefinitely. Why: Every CI push producing a uniquely-tagged image with no cleanup becomes an unbounded, unbudgeted storage cost. Fix: Define retention rules that differentiate release-tagged images (retained per need) from ephemeral images (cleaned up aggressively).
• Pitfall: Locking a multi-cloud organization into a single cloud provider’s native registry with no fallback. Why: A cloud-provider-native registry (ECR) doesn’t natively serve a second cloud environment, and the constraint often surfaces only when that second environment is actually needed. Fix: Evaluate Harbor or another vendor-neutral registry upfront for multi-cloud or hybrid architectures.

Interview Questions

• A production Kubernetes cluster started failing image pulls during a scaling event with Docker Hub rate-limit errors. Walk through the fix. — Tests whether the rate-limit mechanism and the pull-through-cache/native-registry remediation are both understood.
• Why would an AWS-centric team prefer Amazon ECR’s IAM integration over a registry with its own separate credential system? — Tests whether the credential-management simplification is articulated as a concrete operational benefit, not a vague preference.
• Design an image retention policy for a registry accumulating a unique tag on every CI build. — Tests whether release-versus-ephemeral differentiation is the reasoned approach rather than a single blanket rule.
• What’s the difference between a registry and a repository in container terminology? — Tests precise use of terminology often used loosely.
• Why might an organization run Harbor instead of relying entirely on a cloud-native registry? — Tests understanding of vendor neutrality, data residency, and multi-cloud drivers as real architectural considerations.