A self-hosted container registry for private Docker images — on my own infrastructure (Docker Registry v2 with Nginx + SSL), wired into my CI/CD pipeline. This post covers the platform and the knowledge behind it.
Why a private registry
Not every image belongs on a public registry. Internal builds, client-specific images and in-progress work stay private by definition — no accidental exposure, no public pull limits, and full control over the image lifecycle. Everything my pipelines ship is built once, stored here, and pulled from here.
Registry knowledge — layers, tags, digests
A registry is storage for OCI images, and knowing how images are actually structured matters: images are built from layers, referenced by tags, and pinned by digests. Tags are conveniences that move; digests are the immutable truth. That distinction drives everything — reproducible builds pin digests, while tags drive the rolling “latest” workflows.
Access & security
The registry is locked down behind authentication and TLS, with scoped access instead of blanket permissions — pipeline credentials can push to specific repositories but never touch others, and nothing on the registry is ever reachable without credentials. Images are scanned for vulnerabilities as part of the pipeline, before anything gets promoted.
CI/CD integration
The registry is the heartbeat of my pipeline flow: builds push images here, deployments pull them, and rollbacks pull a previous digest. Because everything flows through the registry, promotion and rollback are both simple operations — pick the digest, deploy it.
Operations
Running it myself means owning storage growth, layer garbage collection, retention and backups — and the monitoring that tells me about them before they become problems. A registry is quiet when it works and loud when it fills up.
Outcome
A private, TLS-protected registry on my own infrastructure, scanned and backed up, with every one of my pipelines building, promoting and rolling back through it.