SRJahirTech

Docker Full Tutorial — Part 7: Docker Registry & Image Management

By Suraj Ahir November 25, 2025 6 min read

So far we have been building and running Docker images locally. But in real teams and production environments, you need to share images across machines. A developer builds an image on their laptop, and that same image needs to run on a test server, a staging environment, and eventually production. Docker registries are what make this possible.

What is a Docker Registry?

A Docker registry is a storage and distribution system for Docker images. Think of it as GitHub, but instead of storing code, it stores Docker images. When you run docker pull nginx, Docker downloads that image from Docker Hub — the world's largest public Docker registry, operated by Docker Inc.

There are two types of registries: public registries (Docker Hub, GitHub Container Registry, Quay.io) where anyone can pull images, and private registries where access is controlled by your organization.

Docker Hub — Getting Started

Docker Hub is free for public images and has a free tier for private images. Create an account at hub.docker.com, then log in from your terminal:

# Login (prompts for username and password)
docker login

# Or login with credentials inline
docker login -u yourusername -p yourpassword

# Logout when done
docker logout

Tagging Images Correctly

Before pushing to Docker Hub, your image must be tagged with your Docker Hub username and repository name:

# Build image
docker build -t my-app .

# Tag for Docker Hub
# Format: docker tag local-image:tag dockerhub-username/repo-name:tag
docker tag my-app:latest yourusername/my-app:latest
docker tag my-app:latest yourusername/my-app:v1.0.0

# Push to Docker Hub
docker push yourusername/my-app:latest
docker push yourusername/my-app:v1.0.0

# Pull from Docker Hub (on any machine)
docker pull yourusername/my-app:v1.0.0

Image Tagging Strategy

Tagging is more important than it seems. Bad tagging causes production incidents. Here are professional tagging strategies:

• Semantic versioning — v1.0.0, v1.1.0, v2.0.0. Clear, predictable.
• Git commit SHA — app:a1b2c3d. Ties every image to an exact code commit. Used in CI/CD.
• Branch name — app:main, app:develop. Useful for staging environments.
• latest tag — Always points to the most recent build. Convenient but risky in production — latest on Monday may be different from latest on Friday.

# Tag with git commit SHA
GIT_SHA=$(git rev-parse --short HEAD)
docker build -t yourusername/my-app:${GIT_SHA} .
docker build -t yourusername/my-app:latest .
docker push yourusername/my-app:${GIT_SHA}
docker push yourusername/my-app:latest

Private Registry — AWS ECR Example

AWS Elastic Container Registry (ECR) is a popular private registry for teams using AWS. The workflow is similar but authentication uses AWS credentials:

# Authenticate to ECR
aws ecr get-login-password --region ap-south-1 |   docker login --username AWS --password-stdin   123456789.dkr.ecr.ap-south-1.amazonaws.com

# Tag for ECR
docker tag my-app:latest   123456789.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest

# Push to ECR
docker push 123456789.dkr.ecr.ap-south-1.amazonaws.com/my-app:latest

Running a Local Private Registry

For teams that cannot use cloud registries, Docker itself provides an official registry image you can self-host:

# Run local registry on port 5000
docker run -d -p 5000:5000 --name registry registry:2

# Push to local registry
docker tag my-app:latest localhost:5000/my-app:latest
docker push localhost:5000/my-app:latest

# Pull from local registry
docker pull localhost:5000/my-app:latest

Inspecting Remote Images

# View image history (all layers)
docker history yourusername/my-app:latest

# Detailed image information
docker inspect yourusername/my-app:latest

# Check image size
docker images --format "table {{.Repository}}	{{.Tag}}	{{.Size}}"

In Part 8, we will learn multi-stage builds — a powerful technique to dramatically reduce Docker image sizes while keeping the build process clean and organized.

Image Tagging Strategy

A clear image tagging strategy is essential for production workflows. Avoid relying on the latest tag in production — it is ambiguous and makes rollbacks difficult. Use semantic versioning (myapp:1.2.3) for releases, git commit SHA tags (myapp:abc1234) for traceability, and environment tags (myapp:staging, myapp:production) to track what is deployed where. A common CI/CD pattern builds an image tagged with the git SHA, runs tests against it, then tags it with both the version number and environment tag on successful promotion:

# Tag with multiple tags
docker build -t myregistry/myapp:1.2.3 -t myregistry/myapp:latest .

# Tag an existing image
docker tag myregistry/myapp:1.2.3 myregistry/myapp:production

# Push all tags
docker push myregistry/myapp:1.2.3
docker push myregistry/myapp:production

# List images and their sizes
docker images myregistry/myapp

Private Container Registries

Docker Hub is the default public registry, but production workloads typically use private registries: AWS Elastic Container Registry (ECR), Google Artifact Registry, Azure Container Registry, or self-hosted options like Harbor. Private registries provide access control, vulnerability scanning, and geographic proximity to your deployment environment. Authenticate with a private registry using docker login registry_url before pulling or pushing. In CI/CD systems, use environment variables for credentials rather than storing them in scripts or configuration files.

Practice Exercise

Create a Docker Hub account if you do not have one. Build an image of a simple application, tag it with your Docker Hub username and a version number. Log in with docker login and push the image. Pull it on another machine or after removing the local copy to verify it is accessible from the registry. Also practice pulling a specific version tag versus latest to understand the difference.

Building Cloud Intuition Over Time

Cloud computing is a domain where deep intuition — the ability to make good architectural decisions quickly, to diagnose problems efficiently, and to anticipate how systems will behave under load — develops through accumulated hands-on experience. Every project you build on cloud infrastructure teaches you something that cannot be learned from documentation alone. The cost surprises, the permission errors, the networking debugging sessions, the performance investigations — these are not obstacles to learning, they are the learning. The engineers who have built genuinely deep cloud intuition have usually accumulated it through many projects over several years, not from any single course or certification. Start building things, make mistakes safely in learning environments, and accumulate that experience deliberately.