What is Blue-Green Deployment?

One environment, blue, serves all production traffic. The new version deploys to green, which receives no user traffic and can be tested against real infrastructure. When green passes verification, the router switches all traffic to it.

Blue is kept intact after the switch. If something goes wrong, traffic switches back immediately, which makes rollback nearly instantaneous because the previous version is still running rather than needing redeployment.

Its defining property is that the rollback path is trivial and fast.

• Instant reversal: switching back takes seconds rather than a redeploy cycle.
• Production verification: the new version runs on real infrastructure before receiving traffic.
• Zero downtime: the cutover happens without a service interruption.
• Clean state: each deploy starts from a known environment rather than mutating a running one.

Blue-green doubles the infrastructure required, since two full environments must exist. For large systems this is a substantial ongoing cost.

Shared state is the harder problem. Both environments usually use the same database, so schema changes must be compatible with both versions simultaneously. In flight sessions, queued jobs, and cached data also need handling at the cutover, and a switch that ignores them can drop work.

Blue-green is all or nothing. Traffic moves completely, so if the new version has a defect, every user encounters it until the switch is reversed. The exposure is total but very brief.

Canary is gradual. A small fraction of traffic sees the new version first, so a defect affects that fraction while metrics reveal the problem. Exposure is partial but longer. Blue-green is preferable when verification before cutover is strong and instant rollback matters most. Canary is preferable when defects are more likely to surface under real traffic than in testing, which is usually the case.