Artifact Registries: Docker Hub, Nexus, Artifactory
Your build finishes, your tests go green, and then you hit the quiet question nobody documented: where does the output go? The image, the jar, the npm package - they need a home that the next pipeline stage, the next teammate, and production can all pull from. That home is an artifact registry, and the difference between treating it as a dumb bucket and understanding how it really works is the difference between reliable deploys and the day a moved latest tag silently ships old code.
This guide gives you the mental model first - what an artifact is, why registries exist, and the one rule (immutability) that everything else hangs on. Then the everyday flow of pushing and pulling across Docker Hub, GHCR, Nexus, and Artifactory. Then the production reality: proxying public registries for speed and resilience, private packages, retention, scanning, and exactly why the public-tag-overwrite trap bites teams who thought a tag was a promise.
How to read this
- Want it to actually click? Read in order. Phase 1 installs the immutability mental model that phases 2 and 3 lean on the whole way through.
- Already pushing images and only need the gotchas? Phase 3 is the production phase - proxy repos, retention, scanning, and the tag-overwrite trap. But skim phase 1's immutability section first; it is the reason the trap exists.
The phases
- What a Registry Actually Is - artifacts need a home; what a registry stores, how a tag points at an immutable digest, and why that one distinction governs everything else.
- Pushing, Pulling, and Private Packages - the everyday flow across Docker Hub, GHCR, Nexus, and Artifactory: log in, tag, push, pull, and serve private npm/Maven/PyPI packages from one place.
- Proxying, Retention, Scanning, and the Tag Trap - proxying public registries for speed and resilience, retention so you don't drown in old builds, vulnerability scanning, and why the mutable public tag bites.