On this page
What Is a Blue-Green Deployment?
A blue-green deployment runs two identical environments and swaps traffic between them, giving instant rollback. Learn how it works and its costs.
Quick answer
- Blue-green runs two complete environments and flips all traffic from the old (“blue”) to the new (“green”) at once.
- Rollback is instant: point traffic back at blue.
- It costs roughly double the infrastructure during the switch, since both environments run simultaneously.
What is a blue-green deployment?
A blue-green deployment keeps two identical production environments. One — blue — serves live traffic; the other — green — is idle or running the new version. You deploy and test the new version on green, then switch the router so all traffic goes to green in one step. If something breaks, you switch back to blue. The technique reduces downtime and makes rollback a routing decision rather than a redeploy.
How does it work?
Deploy the new version to green while blue keeps serving. Run smoke tests against green using its own route. When green passes, update the load balancer or DNS to send traffic to green. Watch metrics for a defined period. If healthy, blue becomes the next staging slot; if not, flip traffic back to blue. The key enabler is that both environments are interchangeable and stateless enough to swap.
Why does it matter?
Blue-green gives you near-zero-downtime releases and instant rollback, which is valuable for high-traffic services where a slow rollback is costly. It also lets you validate the new version in a production-shaped environment before exposing it to users.
Where this bites vibecoders
The hidden cost is state. If both environments share one database, a blue-green swap doesn’t protect you from a schema change that breaks blue — old and new code must both work against the shared data. AI-generated deploy scripts rarely account for this: they swap traffic but leave both versions pointing at incompatible data, and the “rollback” doesn’t actually recover the system.
Where AI coding assistants get this wrong
- Swapping traffic without addressing shared database schema compatibility.
- Treating blue-green as a switch with no smoke tests or post-switch monitoring window.
- Under-provisioning, so running both environments causes resource contention.
- Skipping the rollback drill that proves the flip-back actually works.
Checklist
- Make schema changes backward-compatible before the swap.
- Smoke-test the green environment before routing traffic to it.
- Flip traffic in one step and watch error metrics immediately after.
- Rehearse the rollback so it’s a known, one-action procedure.
- Budget for double the resources during the transition.
FAQ
What is the difference between blue-green and canary?
Blue-green moves all traffic at once to the new version; a canary moves a small slice of traffic first and expands gradually. Canary limits the blast radius of a bad release; blue-green optimizes for instant rollback. See What Is a Canary Deployment?.
Does blue-green work with databases?
Only with care. Both environments usually share one database, so any schema or data change must be compatible with both code versions. For incompatible changes, use expand-and-contract migrations rather than relying on the traffic switch.
What is the main downside of blue-green?
Cost and complexity: you run two full environments during the transition, and you must keep routing, config, and data consistent between them. For small apps, a simpler rolling or canary approach is often enough.