How do you tag and push an image to a private registry?
Quick Answer
Build or re-tag the image with the target registry's hostname as a prefix (e.g., myregistry.example.com/myapp:1.0), authenticate with docker login, then docker push. Docker resolves which registry to talk to from the hostname prefix in the image reference, defaulting to Docker Hub only when no hostname is present.
Detailed Answer
The full sequence
docker build -t myapp:1.0 .
docker tag myapp:1.0 myregistry.example.com/myteam/myapp:1.0
docker login myregistry.example.com
# Username: ...
# Password: ...
docker push myregistry.example.com/myteam/myapp:1.0
How Docker knows which registry to talk to
The hostname prefix of the image reference determines the target registry. No special flag is needed on docker push — the destination is fully encoded in the tag:
myregistry.example.com/myteam/myapp:1.0
└────────┬────────┘ └───┬───┘ └─┬─┘ └┬┘
registry host namespace repo tag
docker.io/library/nginx:1.25 (Docker Hub, implicit -- same shape, just defaulted)
If the reference's first segment doesn't look like a hostname (no dot or colon), Docker assumes Docker Hub. If it does look like a hostname — it has a . or :port, or is explicitly localhost — Docker treats it as a private registry address instead.
Authenticating with docker login
docker login myregistry.example.com
Credentials are cached locally in ~/.docker/config.json, in plaintext by default unless a credential helper is configured. Once logged in, later push/pull commands against the same registry don't need re-authentication in the same session.
Common private registry options
- Cloud-provider managed registries — AWS ECR, Google Artifact Registry/GCR, Azure Container Registry. Tightly integrated with each cloud's own IAM system, and often the natural choice if you're already on that cloud.
- Self-hosted registry software — the open-source Docker Registry (the
registry:2image, itself distributed via Docker Hub), or more full-featured options like Harbor, which adds vulnerability scanning, RBAC, and replication. - GitHub Container Registry (GHCR) and GitLab Container Registry — convenient when your source code and CI/CD already live on that platform, since auth can piggyback on the same platform identity.
Why organizations use private registries at all
- Confidentiality — proprietary images shouldn't be publicly pullable, the way an unauthenticated Docker Hub repository would be.
- Access control — a private registry can restrict which teams or services can push or pull which images, following the same least-privilege principle used elsewhere in container security.
- Reliability and control — you're not depending on a third-party public service's availability or rate limits for critical internal pulls.
- Compliance and scanning integration — many private registries integrate with vulnerability scanning and image signing, gating what's allowed to be pushed based on security policy.
Development and testing can reasonably pull common base images straight from Docker Hub. An organization's own proprietary images belong in a private registry, scoped to only the teams and systems that need access.