100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
YAML

Container Registries

How container registries store, version, and distribute Docker images, covering tagging conventions, authentication, and push/pull workflows.

Docker Best PracticesIntermediate8 min readJul 8, 2026
Analogies

What Is a Container Registry

A container registry is a storage and distribution system for Docker images, organized into repositories and tags. Public registries like Docker Hub host open-source images, while private registries (Docker Hub private repos, GitHub Container Registry, AWS ECR, Google Artifact Registry, self-hosted Harbor) store proprietary application images for organizations.

🏏

Cricket analogy: A national sports archive is a storage system for match footage, organized into competitions (repositories) and specific match dates (tags); public archives like a free highlights channel host open matches for anyone, while private archives (a franchise's internal video vault) store proprietary tactical footage only the team can access.

Image Naming and Tagging Conventions

A fully qualified image reference has the form 'registry-host/namespace/repository:tag'. If the registry host is omitted, Docker assumes Docker Hub. Tags identify specific versions; ':latest' is just a conventional tag name, not a special pointer to the newest build, and relying on it in production makes deployments non-reproducible.

🏏

Cricket analogy: A full player reference reads like 'league-name/team-name/player-position:season' — omit the league name and everyone assumes the default local league; and calling someone 'the current star player' instead of naming them by season is just a casual label, not a guarantee it's this year's top performer, making selection unreliable.

text
docker.io/library/nginx:1.27-alpine
ghcr.io/myorg/myapp:2.3.1
123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:2.3.1

Avoid deploying with the ':latest' tag in production. Because it's mutable and gets reassigned on every push, you lose the ability to reliably reproduce or roll back to a known image version.

Authenticating to a Registry

Before pushing to or pulling from a private registry, you must authenticate with 'docker login'. Credentials are stored (by default, in plaintext unless a credential helper is configured) in the Docker config file, so using a credential helper backed by your OS keychain or a cloud provider's credential store is recommended for security.

🏏

Cricket analogy: Before entering a private members-only pavilion, you must show ID at the door (docker login); if the club just writes your ID number on a plain visible list (plaintext storage) that's risky, so better clubs use a proper secure membership card system (credential helper) tied to a verified ID database.

bash
docker login ghcr.io -u myusername
# Enter a personal access token as the password, not your account password

docker login 123456789012.dkr.ecr.us-east-1.amazonaws.com \
  -u AWS --password-stdin

Tagging and Pushing Images

A locally built image must be tagged with the target registry's full path before it can be pushed. 'docker tag' creates an additional reference to the same image ID; it does not duplicate image data on disk.

🏏

Cricket analogy: A player's official league registration record must list their exact team and division before they can be selected for a match; adding that registration label doesn't create a second player, it's just a second official reference pointing at the same person.

bash
docker build -t myapp:2.3.1 .

docker tag myapp:2.3.1 ghcr.io/myorg/myapp:2.3.1

docker push ghcr.io/myorg/myapp:2.3.1

docker pull ghcr.io/myorg/myapp:2.3.1

Immutable Tags and Digests

For maximum reproducibility, reference images by their content digest (a SHA256 hash) rather than a mutable tag. The digest uniquely and immutably identifies the exact image content, which is especially valuable in Kubernetes manifests and CI pipelines where reproducibility matters.

🏏

Cricket analogy: Instead of trusting a vague nickname like 'the current opener' which could mean different players over a career, a scout references the player by their exact unique registration number, which always identifies the exact same individual no matter what nickname changes later.

bash
docker pull ghcr.io/myorg/myapp@sha256:3f8a1c9e2b7d4f6a...

docker inspect --format='{{index .RepoDigests 0}}' myapp:2.3.1

Registry Hygiene: Retention and Scanning

Registries accumulate images quickly across CI builds; most registries support retention policies to automatically expire old, untagged, or stale images. Many private registries also integrate vulnerability scanning on push, blocking or flagging images with known critical CVEs before they can be deployed.

🏏

Cricket analogy: A club's video archive fills up fast with every single net session recorded; a retention policy automatically deletes untagged practice footage after 90 days, while a review board scans every match recording for disciplinary incidents before it's approved for public broadcast.

Semantic versioning tags (e.g., 2.3.1) combined with immutable digests give you both human-readable version tracking and cryptographic reproducibility — use semver tags for humans and digests for automated deployment pinning.

  • A registry stores images as repositories with one or more tags
  • The ':latest' tag is just a convention and should be avoided in production deployments
  • docker login authenticates to a registry; prefer credential helpers over plaintext storage
  • docker tag creates a new reference to existing image data, it does not copy it
  • Content digests (sha256) provide immutable, reproducible image references
  • Registries should enforce retention policies and vulnerability scanning on push

Practice what you learned

Was this page helpful?

Topics covered

#YAML#DockerKubernetesStudyNotes#DevOps#ContainerRegistries#Container#Registries#Registry#Image#Docker#StudyNotes#SkillVeris