Where Your Builds Live: Why Every Artifact Needs a Home

Imagine this: your CI pipeline just turned green. A developer asks, "Which build should we deploy to staging?" Someone replies, "The one from yesterday's run, I think." Another person chimes in, "No, I rebuilt it locally this morning. Use mine."

This conversation happens more often than teams like to admit. When artifacts live on laptops, in CI workspace folders, or in someone's shared drive, you lose the ability to consistently know what's actually ready to deploy. Staging might get one version, production gets another, and nobody can trace which artifact caused the incident at 2 AM.

The fix is simple in concept but critical in practice: you need a single, centralized place where every build result lives. In DevOps terms, that place is called a registry or a repository manager.

Artifacts Come in Different Shapes

Let's start with the familiar kind of artifact: a JAR file, a ZIP archive, a compiled binary, or a NuGet package. These are single-file artifacts. Tools like Nexus, Artifactory, or the built-in package registries of your language ecosystem (npm registry, Maven Central, PyPI) handle these well. They store the file, track versions, and let pipelines or developers pull the exact dependency they need.

Now consider container images. A container image is not a single file. It's built from multiple layers stacked on top of each other. You cannot store a container image in a regular artifact repository. It needs a container registry: Docker Hub, Amazon ECR, Google Container Registry, or Harbor. Container registries understand the layer structure. When you pull an image, the registry only sends the layers that don't already exist on the target machine. This makes deployments faster and saves bandwidth.

Container images have become the most common artifact type in modern CI/CD pipelines. But the principle is the same regardless of format: the registry is the single source of truth for every artifact that passed your build and tests.

The Registry Is the Handoff Point Between CI and CD

Here is the most important function of a registry in a pipeline: it marks the boundary between continuous integration and continuous delivery.

The following diagram contrasts the correct flow with the broken flow that occurs when no registry exists.

Look at the flow. CI's job ends the moment an artifact lands in the registry with a clear version tag. The build is done. The tests passed. The artifact is stored. CI's responsibility stops there.

CD starts from the registry. CD does not rebuild the artifact. It pulls the exact same artifact that CI stored, then deploys it to the target environment. No recompilation. No different dependencies. No "I think this is the same build."

This separation is not just technical. It is about ownership. CI owns the correctness of the build. CD owns the correctness of the deployment. If something breaks in production, you trace back to the exact artifact in the registry. You know its version, its commit hash, its build timestamp. There is no guessing.

Promotion Without Modification

A good registry also enables artifact promotion. Promotion is the process of marking a specific artifact as ready for the next environment. You do not modify the artifact itself. You add metadata.

For example, your CI produces an artifact tagged 1.2.3-build.45. That artifact sits in the registry. When it passes staging tests, you add a tag: staging. When it passes production validation, you add another tag: production. The underlying artifact is identical. Only its status changes.

This matters because it keeps a clean audit trail. You can always see which version was promoted to which environment and when. Without this mechanism, teams end up rebuilding for each environment, introducing subtle differences between what was tested and what is running in production.

What Happens Without a Registry

Teams that skip setting up a proper registry run into the same problems repeatedly:

• Developers ask each other which build to deploy.
• Staging runs a different version than production.
• Rollbacks become guesswork because nobody knows what was actually running before.
• Security scans run on some builds but not others because there is no central inventory.
• Compliance audits turn into manual email chains trying to reconstruct what was deployed six months ago.

A registry eliminates all of these. It is not a luxury. It is the foundation that makes disciplined pipelines possible.

Practical Checklist for Setting Up Your Registry

If you are setting up a registry for the first time, or reviewing your current setup, here is a short checklist:

• Choose the right type: container registry for images, artifact repository for binaries and packages. Some tools like Harbor or Artifactory handle both.
• Enforce immutability: once an artifact is stored with a version tag, do not allow overwrites. A new build gets a new version.
• Set retention policies: not every build needs to live forever. Keep the last N builds or builds from the last M days. Archive or delete the rest.
• Control access: pipelines should have write access. Developers and CD pipelines should have read access. Use IAM roles or tokens, not shared passwords.
• Tag promotions explicitly: use metadata or tags to mark which artifacts are in staging, production, or rolled back. Automate this in your CD pipeline.

The Concrete Takeaway

A registry is not just storage. It is the contract between your build process and your deployment process. It ensures that what was built is exactly what gets deployed. It gives your team a single place to look when something goes wrong. It makes promotion traceable and rollbacks reliable.

Set up your registry before your next deployment. Your future self, debugging an incident at midnight, will thank you.