Your own container registry
If you build containers, you are pulling them from somewhere on every deploy. Running your own registry keeps those pulls fast, private and free of other people’s rate limits.
A registry is where your built images live between build and run. The upstream public registries rate-limit pulls and see everything you push; your own does neither. The simple registry image gets you started; Harbor adds a UI, accounts and scanning.
Plain registry or Harbor
- The
registry:2image — one container, a config file, done. Fine for a team that trusts itself. - Harbor — adds web UI, user accounts, image signing and vulnerability scanning. More to run, worth it once more than a few people push.
TLS or it will not work
Docker refuses to talk to a registry over plain HTTP unless you add insecure-registry exceptions on every client — which you should not. Put it behind TLS with a real certificate from the start. See TLS certificates.
Storage fills quietly
Every pushed tag keeps its layers. Push to :latest a hundred times and you have a hundred old image versions on disk. Enable garbage collection and a retention policy — Harbor does this on a schedule — or the registry volume grows until it stops the server. See a disk that fills up.
Lock down who can push
Anyone who can push can replace the image your production servers run next. Require authentication for push, keep pull open only if that suits you, and use robot accounts for CI rather than a person’s credentials. See managing secrets.
Scan what you ship
If you run Harbor, turn on scanning so a known-vulnerable base image is flagged before it reaches production. It is the container equivalent of keeping packages patched.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base