Blue-green deployment maintains two identical production environments simultaneously. At any moment, one (blue) is live and the other (green) is idle. To deploy, run the new version on green, run smoke tests, then switch the load balancer to point to green.

Downtime during deployments causes lost revenue and frustration. Deployment failures require rollback which can take hours if old infrastructure is torn down, during which the system is unavailable.

The switch happens in seconds via load balancer or DNS change. If the new version has critical bugs, rollback is equally fast by pointing traffic back to blue. The cost is running two full production environments (doubled infrastructure), and database schema migrations must be backwards-compatible since both versions run against the same data. Compare with Canary release, which gradually shifts traffic instead of switching all at once.

The diagram shows the three phases: Blue running live while Green is deployed and tested, then an instant switch to Green, and a standby Blue ready for immediate rollback.

Before:  Load Balancer → Blue (v1.0, live)
                     ⤳ Green (v2.0, idle)

Deploy:  1. Deploy v2.0 to Green
         2. Run smoke tests on Green
         3. Verify Green is healthy

Switch:  Load Balancer → Green (v2.0, live) [instant]
                     ⤳ Blue (v1.0, idle, ready for rollback)

Rollback: Load Balancer → Blue (v1.0, live) [if needed, seconds]
                      ⤳ Green (v2.0, idle)