release-engineering

Blue-Green Deployment

Blue-green deployment runs two identical production environments and switches all traffic from the old one to the new one at once. If the new version fails, you switch straight back.

What it means

Blue-green deployment keeps two full production environments side by side. One (blue) serves live traffic while the other (green) sits idle running the new version. You deploy and test against green with no user impact, then flip the router so all traffic moves to green in a single cutover. Blue is kept warm as the fallback, so if the new release misbehaves you flip back instantly. The two environments are meant to be identical in configuration, differing only in the software version they run.

Why it matters

The appeal is a near-instant rollback and effectively zero downtime during the switch. Because the new version is fully warmed up before it takes traffic, users do not see the cold-start hiccups a rolling deploy can cause, and reverting is just another router flip rather than a redeploy. The cost is that you run double the infrastructure for the switchover window, and because the cutover is all-or-nothing, a bug that only shows under real load hits 100 percent of users at once - unlike a canary, which exposes it gradually.

In practice

Blue-green is often combined with flags: you cut infrastructure over blue-green for the platform change, then use feature flags to release the actual new features gradually on top of it. Harness orchestrates blue-green swaps in its pipelines, and LaunchDarkly handles the feature-level rollout once the new environment is live. Our rollout strategies guide compares blue-green against canary and progressive approaches.

Related Terms

Learn More

Related Articles

Free Newsletter

Get the Feature Flags Newsletter

Platform benchmarks, real pricing data and progressive delivery practice. No spam.

Free. Unsubscribe any time. See our privacy policy.