What an Artifact Registry Is¶
A CI/CD pipeline builds something — a container image, a compiled package, a Helm chart — from source. That build output needs a durable, versioned home that exists independently of the runner that built it, so everything downstream (a deploy, another pipeline, a teammate) can pull the exact same bits instead of rebuilding from source and hoping the result matches. An artifact registry is that home.
TL;DR — in 30 seconds:
- The core rule: build once, reuse everywhere — a pipeline publishes an artifact to the registry a single time, and every consumer pulls that stored artifact instead of rebuilding it.
- Rebuilding from source at deploy time is not the same as pulling what CI already built and tested — base images, dependency resolution, and even the clock can drift between the two builds.
- "Artifact" is broader than "container image": packages (npm, Maven, PyPI), Helm charts, Terraform modules, and generic binaries all need the same durable, versioned home.
1. Why not just rebuild it¶
flowchart LR
A["CI pipeline builds<br/>from source, once"] -->|"push"| B["Artifact registry"]
B -->|"pull, never rebuild"| C["Deploy target"]
B -->|"pull, never rebuild"| D["Another pipeline / consumer"]Imagine a deploy step that rebuilds the image from source instead of pulling a previously built one. That looks harmless — same Dockerfile, same source commit — but the build is not guaranteed to be identical:
- A base image tag (e.g.
python:3.12) can resolve to a different underlying image tomorrow than it did today, if the upstream maintainer pushed a patch update to that tag. - A dependency range in a lockfile-less install can resolve to a newer minor version at build time.
- Whatever CI actually tested was one specific set of bytes — a rebuild produces a different set of bytes that merely shares the same source, and was never itself tested.
A registry closes that gap: CI builds and tests one artifact, publishes it once, and every later step — staging, production, a rollback — pulls that same, already-tested artifact. Nothing downstream ever rebuilds.
2. What actually lives in a registry¶
| Artifact type | Example registry |
|---|---|
| Container images | GHCR, ECR, Docker Hub, Nexus, Artifactory |
| Language packages (npm, Maven, PyPI, etc.) | Nexus, Artifactory, or the language's own public registry |
| Helm charts | An OCI-compatible registry (most container registries now support this), or a chart repo |
| Generic binaries / build outputs | Nexus, Artifactory, or a cloud storage bucket used as a raw-file registry |
The common thread: each of these is a build output, not source code. Source lives in git, forever editable; an artifact, once published, is meant to be fixed — see the next page for what that guarantee actually requires.
Common gotchas
- Treating the registry as a backup of source control. Fix: a registry holds build outputs: it's not a substitute for git history, and it's not where you go to recover source code.
- Assuming "container registry" covers every artifact type a team produces. Fix: a shop that also ships npm packages or Maven artifacts needs a registry (or repo manager) that handles those formats too — see the next page for registries that do both.
Check yourself — a deploy pipeline rebuilds the image from source at deploy time instead of pulling a previously built one from the registry. What's the specific, easy-to-miss risk?
The rebuild can silently produce different bytes than what CI actually tested — a floating base image tag or an unpinned dependency can resolve differently between the two builds — even though the source commit is identical. The registry exists precisely so nothing downstream ever needs to rebuild: it pulls the one artifact that was actually tested.
Done when: you can explain, in one sentence, why "same source commit" does not guarantee "same build output," and why that's the reason an artifact registry exists.