Pushing to a Private Registry

In one line

Docker Hub is fine for learning and public open-source images, but real companies push their proprietary images to a private registry — the mechanics are nearly identical, just pointed somewhere else.

0/4 · 0%

Key ideas

01
A PRIVATE REGISTRY works exactly like Docker Hub conceptually (Topic 1.4) — it stores and serves images by name+tag — but access is restricted to authenticated, authorized users/systems, and it's typically run by your own company or a cloud provider on your behalf.
02
Common real options: AWS ECR (Elastic Container Registry), Google Artifact Registry, Azure Container Registry (cloud-managed, tightly integrated with each provider's other services), or self-hosted options like Harbor or a private Docker Registry instance — all serve the same fundamental purpose.
03
docker login <registry-url> authenticates your local Docker client against a specific registry (you can be logged into MULTIPLE registries simultaneously — Docker Hub AND your company's private ECR, for instance).
04
To push to a NON-default registry, your image's TAG must include that registry's hostname as a prefix: docker tag myapp:v1 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:v1 — the registry hostname embedded in the tag is literally how Docker knows where docker push should send it.
05
Cloud-managed registries (ECR, Artifact Registry) typically require a specific authentication flow beyond a plain username/password — usually a short-lived token obtained via the cloud provider's own CLI (aws ecr get-login-password | docker login --username AWS --password-stdin ...), reflecting these platforms' broader identity/access-management systems.
06
A private registry is also where automated vulnerability scanning (Phase 7.2) often happens AUTOMATICALLY on every push, and where access-control policies (which teams/services can pull which images) get enforced — genuinely more than 'Docker Hub but private,' it's usually a real piece of your security and compliance infrastructure.

In your stack

→
A typical real Java team's pipeline: a CI job builds a Spring Boot image, tags it with BOTH a semantic version (myapp:1.4.2) AND the git commit SHA (myapp:a1b2c3d) for full traceability, pushes both tags to a private ECR repository, and a deployment tool later pulls the specific tag it needs from there — the developer's own laptop is never involved in production deployment at all.

Code & diagrams

private-registry-workflow.shmarkdown

The exact tag-and-push flow for a non-default registry.

# Authenticate to a private registry (varies by provider — this is the AWS ECR pattern)
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com

# Tag your LOCAL image with the full registry-prefixed name it needs to have to be pushed there
docker tag myapp:v1 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

# Push it
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

# Anyone (or any system) with access can now pull the EXACT same image
docker pull 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

Explain it without notes

Why does pushing an image to a private registry require an extra docker tag step that pushing to Docker Hub doesn't strictly need?

Why would a company's security team care about WHICH registry an image comes from, not just what's inside it?

Practice

If you have access to any cloud provider's free tier, create a private registry repository and push a small test image to it, following that provider's specific authentication flow.

Write down, from memory, the exact 3-step sequence (authenticate, tag, push) for getting a locally-built image into a private registry.

Trade-offs

↔
Cloud-managed registries (ECR, Artifact Registry) reduce operational burden (no server to maintain yourself) in exchange for vendor lock-in and often per-GB storage/transfer costs — self-hosting (Harbor) gives full control at the cost of running and securing that infrastructure yourself; most teams reasonably default to their cloud provider's managed option unless they have a specific reason not to.

Done when you can

I can tag and push an image to a non-default registry from memory.
I understand why the registry hostname must be embedded in the image tag.
I can explain why a private registry is a security control, not just extra storage.

Command Palette