Build vs Deploy vs Release: What's the Difference?

Quick answer
Build turns source code into an artifact; deploy places that artifact in an environment; release makes the change reachable by users.
The three are separable, and separating them is what makes zero-downtime deploys, canaries, and instant rollback possible.
A feature flag is the clearest example: the code is deployed but not released until the flag is enabled.
Hosted platforms collapse all three into a push to main, which is convenient until a database migration makes the previous version unable to run.
The practical rule is build once, deploy the same artifact everywhere, and release separately when the change is risky.

What is the difference between build, deploy, and release?

A build is a transformation: source plus dependencies plus a toolchain produce an artifact with a digest. A deploy is a placement: that artifact is installed and started in an environment, whether a laptop, a staging cluster, or production. A release is a visibility decision: users can now reach the new behaviour.

The distinction is not academic. If the same bytes are deployed to staging and production, staging results mean something. If the release is controlled separately, a deploy can happen in the morning and the release can wait for a support engineer to be online. Both properties come from keeping the steps apart.

Why does the distinction matter in practice?

Because each step has a different failure mode and a different undo. A bad build is fixed by reverting a commit and rebuilding. A bad deploy is fixed by redeploying the previous artifact. A bad release is fixed by turning a flag off, which takes seconds and does not touch the running binary.

Collapsing the steps means every undo is the most expensive one available. If build, deploy, and release happen only together, the smallest possible correction is a new build plus a full deploy, and the slowest thing in that chain determines your recovery time.

| Step    | Question it answers              | Output                      | How to undo                    |
|---------|----------------------------------|-----------------------------|--------------------------------|
| Build   | Is this commit valid?            | Artifact with a digest      | Revert, rebuild                |
| Deploy  | Is this artifact running?        | Running version in an env   | Redeploy previous artifact     |
| Release | Can users reach the new path?    | Traffic or flag change      | Disable flag, route back       |

How do feature flags separate deploy from release?

A flag wraps the new code path and defaults to off in production. Deploying then ships inert code, which can be verified in the running environment without exposing it: the process starts, migrations run, and nothing user-facing changes. Releasing is a configuration change, and unreleasing is the reverse.

Flags are not free. Each one is a branch in production that must be removed once the change is permanent, or the code accumulates combinations nobody tests. The discipline is to give every flag an owner and an expiry date at creation, and to delete it when the release is complete.

Where do AI-generated apps blur the line?

On platforms like Vercel, Netlify, and Railway, a merge to main builds, deploys, and releases in one operation. That is a reasonable default for a stateless frontend, because all three steps are fast and the undo is another push. It becomes dangerous when the change includes a schema migration or a destructive background job.

The review question is not whether the platform is doing too much, but whether the change can tolerate the previous version running alongside the new one for a few minutes. If it cannot, the change needs a separate migration step and a flag, even if the host would happily ship it in one push.

Where this bites vibecoders
AI assistants describe the deploy as if it were the release: the code is live, so the feature is live. That assumption breaks the first time a migration makes the old and new version incompatible, because there is no state in which both can run. Asking whether the previous artifact still works after the migration is the whole compatibility check.

Where AI coding assistants get this wrong

Treating a successful deploy as proof the feature is released and working for users.
Adding a feature flag with no owner, no expiry, and no removal task.
Running a schema migration in the same step as the deploy it is meant to support.
Rebuilding the app for each environment instead of promoting one artifact.
Assuming the host’s instant rollback also reverses database changes.
Releasing to all users at once when a flag or canary was available.

Checklist

Name the artifact and its digest for every deploy.
Deploy the same artifact to every environment.
Put risky user-facing changes behind a flag that defaults off.
Give every flag an owner and an expiry date.
Keep migrations backward-compatible for one release cycle.
Write down how to undo a build, a deploy, and a release separately.

FAQ

Is a release the same as a deployment?

No. A deployment makes an artifact run in an environment; a release makes its behaviour reachable by users. With a feature flag, the deployment can happen days before the release. On a platform that auto-deploys on push, they coincide, which is why the difference is easy to miss.

What does build once, deploy many mean?

Build the artifact a single time, store it by digest, and deploy that exact artifact to every environment. Rebuilding per environment can resolve different dependency versions or base images, so a staging pass no longer predicts production. Build once is what makes promotion meaningful.

Can you release without deploying?

Yes, if the code is already deployed and inert behind a flag or a disabled route. That is the normal pattern for a staged rollout: deploy the code, verify it is running safely, then enable it for a small percentage and widen. The release is a configuration change, not a deploy.

Why does rollback sometimes not work?

Because the database changed and the old artifact expects the old schema. Application rollback is only reliable when migrations are backward-compatible for at least one release. If a migration drops or renames a column the previous version reads, redeploying the old image will not restore service.