Why You Should Never Rebuild for Production

A few weeks ago, a team I worked with had a strange problem. Their staging environment passed every test. The QA team signed off. The product owner gave the green light. But when they deployed to production, users started seeing errors that never appeared during testing.

The team spent two days debugging. They compared configuration files, checked environment variables, and reviewed the code changes. Everything looked identical. Finally, someone noticed the build timestamps were different. The artifact running in production was not the same artifact that passed all those tests in staging.

This is a story that repeats across teams every day. The root cause is almost always the same: somewhere between staging and production, someone decided to rebuild the application instead of promoting the existing artifact.

The Two Paths: Rebuild vs. Promote

Every software delivery pipeline has multiple environments. Development for trying new features. Staging for verification by QA or product owners. Production where real users interact with your application.

When you need to move an artifact from one environment to the next, you have two choices.

Rebuild means taking the source code from a specific commit and running the build process again for the target environment. The pipeline checks out the code, downloads dependencies, compiles the application, and produces a new artifact.

The following flowchart illustrates the two paths and their outcomes:

flowchart TD A[Start: Need to deploy to production] --> B{Choose path} B --> C[Rebuild] B --> D[Promote] C --> E[Checkout source code] E --> F[Download dependencies] F --> G[Compile application] G --> H[New artifact with new checksum & timestamp] H --> I[Deploy to production] I --> J[Risk: different from tested artifact] D --> K[Existing artifact in registry] K --> L[Mark as approved for production] L --> M[Deploy same bytes to production] M --> N[Certainty: matches tested artifact]

Promote means taking the artifact that already exists in your registry, the one that was already built and verified in a previous environment, and marking it as approved for the next environment. No new build. No new compilation. Just a metadata change that says "this artifact is now allowed in production."

These two approaches sound similar, but they produce fundamentally different outcomes.

The Hidden Risk of Rebuilding

When you rebuild for production, you are creating a new artifact. It has a different build ID. A different timestamp. And critically, the dependencies downloaded during this new build might be different from the ones used in the staging build.

Consider what happens when your build process runs npm install, pip install, or go mod download. These commands reach out to remote repositories to fetch packages. If a package maintainer pushed a minor update between your staging build and your production build, your production artifact will include that update. Even if the change is technically backward-compatible, it introduces a difference between what you tested and what you are running in production.

The same risk applies to your toolchain. If your CI system updates the compiler version, the base image, or the build tools between builds, the output can change in subtle ways. Code that compiled fine during the staging build might produce different machine instructions during the production build.

You lose the certainty that what was tested is what is running in production. You move from confidence to hope.

Why Promote Works Better

Promotion eliminates this uncertainty. The artifact is built once, stored in your registry, and verified in staging. When it passes all checks, you promote it to production by updating its metadata or tags. No new compilation. No new dependency downloads. The exact same bytes that ran in staging are now running in production.

In practice, promotion usually works through tagging. In a container registry, you might have an image tagged as staging. After verification, you add a production tag to the same image. The image itself does not change. Only the labels change. Your deployment system watches for the production tag and pulls the image when it appears.

This approach also simplifies rollbacks. If the new version causes problems in production, you point back to the previous promoted artifact. You do not need to rebuild from an old commit, hoping that the dependencies and toolchain from three months ago are still available. The old artifact is already in your registry, exactly as it was when it was promoted before.

Verification Still Happens Before Promotion

Promotion does not mean skipping verification. Before an artifact moves from staging to production, it should pass a defined set of tests. Unit tests, integration tests, and any environment-specific checks that make sense for your application. These tests run against the artifact in staging. If they pass, the artifact is promoted. If they fail, the artifact stays in staging, and the team fixes the source code, rebuilds, and starts the verification process again.

The key difference is that verification and promotion use the same artifact. You are not testing one version and deploying another.

When Rebuild Might Be Necessary

There are legitimate cases where rebuilding is the right choice. If your artifact includes environment-specific configuration that must be baked into the build, you might need separate builds for each environment. If your compliance requirements demand that production artifacts are built in a separate, more secure pipeline, you might have to rebuild.

But these cases are exceptions, not the rule. Most teams can separate configuration from code. Most compliance requirements can be satisfied by signing artifacts after promotion rather than rebuilding them. If you find yourself rebuilding for production regularly, ask whether the reason is technical necessity or just habit.

Practical Checklist for Artifact Promotion

Before you set up your promotion workflow, verify these points:

  • Your build process produces a single artifact that works across environments
  • Your registry supports tagging or metadata updates without re-uploading
  • Your deployment system can watch for tag changes and trigger deployments
  • Your rollback process references previously promoted artifacts, not old commits
  • Your team understands that "promote" means changing metadata, not rebuilding

The Concrete Takeaway

The decision between rebuild and promote comes down to one question: do you want to be certain that what you tested is what you deployed, or do you want to hope that the new build produces the same result?

Promotion gives you certainty. Rebuild gives you hope. In production, certainty matters more than hope. Build once, verify thoroughly, promote confidently. Your users will thank you, and your debugging sessions will be shorter.