Blue-Green Deployment
Running two identical production environments and flipping traffic from old to new all at once — instant cutover, instant rollback, double the infrastructure.
What is blue-green deployment?
Blue-green deployment releases new software by running two identical production environments — call them blue (current) and green (new). You deploy the new version to the idle environment, test it fully while the live one keeps serving users, then switch all traffic at once (typically by repointing a load balancer or DNS) from blue to green. If something goes wrong, you flip back to blue instantly. It’s the deployment strategy optimized for fast, clean cutover and instant rollback.
The tradeoff: instant rollback vs double infrastructure
Blue-green’s defining virtue is rollback speed: because the old environment stays fully running and ready, reverting is just flipping the switch back — no re-deploy, no scramble, seconds not minutes. That makes it excellent for releases where you need a guaranteed, immediate escape hatch. The cost is equally clear: you run two full production environments, at least during the transition, which roughly doubles infrastructure for that window (cloud elasticity softens but doesn’t eliminate this). Compared to a canary release, blue-green does not expose the new version to a small slice of real traffic first — it’s all-or-nothing, so a bug that only surfaces under real production load hits everyone the moment you switch, rather than a 5% canary cohort. The strategies target different risks: canary limits blast radius, blue-green optimizes cutover and rollback speed.
The parts that actually bite
The mechanics people underestimate are stateful. Database schema changes are the hard problem: both environments typically share one database, so migrations must be backward-compatible — the schema has to work for both old and new versions simultaneously, or your instant rollback isn’t actually instant (you can’t un-migrate as fast as you can flip traffic). In-flight sessions and connections need draining so users mid-request aren’t dropped at the switch. And stateful workloads (long-lived connections, in-memory session state) complicate the clean cutover the model assumes. Blue-green is cleanest for stateless services fronting a carefully-migrated shared datastore.
What people get wrong
- Non-backward-compatible migrations — a schema change that only the new version understands breaks the instant-rollback promise.
- Expecting canary-style safety: blue-green flips everyone at once, so load-dependent bugs hit 100% of users, not a small cohort.
- Ignoring in-flight requests — without connection draining, the traffic switch drops users mid-transaction.
Primary source: Martin Fowler: BlueGreenDeployment
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.