What is Blue-Green Deployment?

#How blue-green works

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.

#Why blue-green is used

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.

#Limits and costs

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 vs canary

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.

#Key takeaways

• Two identical environments alternate serving traffic, with the previous version kept running for instant rollback.
• It requires roughly double the infrastructure for the duration of the deployment.
• Shared databases mean schema changes must be compatible with both versions at once.
• Blue-green trades total but brief exposure against canary's partial but longer exposure.

#Frequently asked

How long should the old environment stay up?

Long enough to be confident the new version is healthy under real traffic, commonly one to several hours, and through at least one peak period.

How are database migrations handled?

With backward compatible changes applied before the switch, so both versions work against the same schema. Expand and contract migrations are the standard pattern.

Is blue-green practical for large systems?

It gets expensive. Large systems often use canary or rolling deployments instead, reserving blue-green for components where instant rollback justifies the cost.