Blue-green deployment is a release strategy where two identical production environments (called blue and green) are maintained simultaneously. At any moment, one environment is live and the other is idle. To deploy a new version, you deploy it to the idle environment, run smoke tests, then switch traffic from the live environment to it.

users → load balancer → [blue: v1.2  (live)]
                         [green: v1.3 (staging)]

after switch:
users → load balancer → [blue: v1.2  (standby)]
                         [green: v1.3 (live)]

The switch is typically a single change to the load balancer or DNS, which takes effect in seconds. If the new version has a critical bug, the rollback is equally fast: point the load balancer back at the old environment. The old version is still running and warm.

The primary benefit is near-zero-downtime deployments and instant rollback. The cost is running two full production environments simultaneously, which doubles infrastructure cost. For large deployments this is significant; for smaller services it is often acceptable.

Blue-green deployment requires that both environments can operate against the same data stores. Database schema migrations need to be backwards-compatible: the old version must be able to read data written by the new version during the transition period. This is the main constraint that complicates blue-green in practice.

Compare with Canary release, which gradually shifts traffic to the new version rather than switching all at once.