Where Does Your Build Go? The Missing Piece Between Code and Production

You just finished building your application. The build succeeded, tests passed, and you have a shiny new artifact sitting in a folder on your laptop. Now what?

If you're like most teams setting up their first pipeline, the next step feels obvious: deploy it. But there's a problem hiding in plain sight. That artifact on your laptop is useless to the production server sitting in a data center or cloud region. It can't reach into your local folder and grab the file. Even if the build ran on a dedicated CI machine, the deployment target still can't access files sitting on that machine's local disk.

This is where most pipeline designs hit their first real snag. You need a place to put the artifact where both the build process and the deployment target can reach it.

The Shared Storage Problem

Think about what happens when you finish cooking a meal for a party. You don't keep the food in your kitchen and expect guests to walk in and serve themselves from your stove. You put the food on a table where everyone can reach it.

Artifacts work the same way. The build process creates the artifact. The deployment process needs to retrieve it. These two processes might run on different machines, in different networks, at different times. They need a shared location that both can access over the network.

This shared location is called an artifact registry or artifact repository. Its job is simple: store artifacts and provide a way to fetch them. Every time a build finishes, it pushes the artifact to this registry. Later, when a deployment starts, the target server pulls the artifact from the registry and runs it.

The following diagram shows the basic flow:

Here is how you push an artifact after a build and pull it on a deployment target:

# On the build machine: push the artifact to the registry
curl -X POST \
  -F "file=@myapp-v1.2.3.jar" \
  https://registry.example.com/upload

# On the deployment target: pull the artifact from the registry
curl -O https://registry.example.com/artifacts/myapp-v1.2.3.jar
flowchart TD A[Build Machine] -->|push artifact| B[Artifact Registry] B -->|pull artifact| C[Deployment Target] D[Different Network] -.-> A E[Different Network] -.-> C F[Different Time] -.-> A G[Different Time] -.-> C

More Than Just a File Server

A registry does more than hold files. It also keeps metadata about each artifact: version number, creation timestamp, and often the Git commit hash that produced it. This metadata becomes critical when something goes wrong in production.

Imagine you deploy version 2.3.1 and users start seeing errors. You need to know exactly what code changes went into that artifact. Without metadata linking the artifact back to its source commit, you're guessing. With it, you can check the diff, identify the problem, and decide whether to roll back or fix forward.

Some registries also support labels or tags. You might tag an artifact as "staging-validated" after it passes integration tests, or "production-ready" after manual approval. These tags help automate which artifacts get deployed to which environment.

The Connectivity Trap

Here's a mistake that catches many teams: they set up a registry in the cloud, but their production servers run in a private network that can't reach the public internet. The build pushes artifacts successfully, but when the deployment tries to pull, it fails with a connection timeout.

The registry must be accessible from every server that needs to deploy. If your production environment is isolated, your registry needs to be inside that same network, or you need a mechanism to sync artifacts across network boundaries. Some teams run a local proxy or mirror that caches artifacts from a central registry. Others use a registry that supports private networking endpoints.

This sounds obvious when you read it, but it's easy to overlook when you're focused on getting the pipeline working end to end. Check connectivity before you build your entire deployment process around a registry that your servers can't reach.

Immutability Matters

A good registry prevents artifacts from being modified after they are stored. This property is called immutability. It means the artifact you store today will be identical to the artifact you retrieve six months from now.

Why does this matter? Without immutability, you can't trust what you're deploying. Someone could modify an artifact after it passed testing. A bug that was caught in staging could reappear in production because the artifact changed between environments. Debugging becomes a nightmare because you're never sure if the artifact running in production matches what was tested.

Immutability forces a clean workflow: every change produces a new artifact with a new version. There's no "update in place" for artifacts. If you need to fix something, you rebuild and create a new version. This discipline makes deployments predictable and rollbacks straightforward.

Decoupling Build from Deploy

With a registry in place, build and deploy become two separate processes that can run independently. The build finishes, pushes the artifact, and moves on. The deployment can happen minutes, hours, or days later. The artifact sits safely in the registry, waiting to be retrieved.

This decoupling is powerful. You can build and test an artifact in the morning, have it reviewed by a senior engineer in the afternoon, and deploy it to production at night when traffic is low. Each step happens on its own schedule, but they all reference the same immutable artifact.

It also means you can rebuild and redeploy the same artifact to multiple environments. The artifact that passed staging tests is the exact same artifact that goes to production. No recompilation, no environment-specific builds, no "it worked on my machine" surprises.

A Quick Practical Checklist

When setting up your artifact registry, verify these points:

  • Accessibility: Can every server that needs to deploy reach the registry over the network?
  • Immutability: Does the registry prevent modification of stored artifacts?
  • Metadata: Does each artifact carry version, timestamp, and source commit information?
  • Retention: How long do you keep old artifacts? Do you have a cleanup policy?
  • Authentication: Who can push artifacts? Who can pull them? Are credentials rotated?

The Takeaway

Your build output needs a home that both the build process and deployment targets can reach. An artifact registry provides that shared storage, keeps metadata for traceability, enforces immutability so you can trust what you deploy, and decouples build from deploy so each step can happen on its own timeline. Without it, your pipeline is just a build that ends with a file sitting on a machine nobody can reach.