Blue-Green Deployment
A deployment strategy that uses two identical production environments (Blue and Green) to minimize downtime and risk.
Detailed Explanation
Only one environment is live at a time. To deploy a new version, you update the idle environment and run tests. Once verified, you switch the load balancer to point to the new version. This allows for instant rollbacks, if something goes wrong, you simply switch the traffic back to the original environment.
Quick Summary
Blue-green deployment runs two identical production environments and flips traffic between them with a single switch. Rollback is instantaneous because the previous version is still running, fully scaled, in the other color.
Key Takeaways
- At any moment, one color is live and the other is dark , the deploy is the moment you flip the router.
- Rollback is as fast as the forward switch, which is the headline benefit over rolling updates.
- Doubles infrastructure cost during deploys; outside the deploy window the idle color can be scaled down.
- Long-running connections (WebSockets, server-sent events) need careful drain handling at switch time.
- Database schema must work for both colors simultaneously, just like any other zero-downtime strategy.
When to use it
- High-risk releases where instant rollback is non-negotiable.
- Regulated environments where every release must be auditable and reversible.
- Apps with simple traffic patterns that don't need gradual rollouts.
- Teams without sophisticated canary tooling who still want zero-downtime deploys.
Common Mistakes
- Forgetting that the database is shared , schema changes have to be backward-compatible across colors.
- Cutting over before the new color is fully warm; cold caches and JIT compilation cause an immediate latency spike.
- Skipping post-switch monitoring and assuming "green" tests on the new color guarantee production behavior.
- Never actually exercising rollback; the first real rollback during a 3 AM incident is the wrong time to find bugs in the procedure.
Blue-Green Deployment, Frequently Asked
Blue-green vs. canary release?
Blue-green flips 100% of traffic at once with instant rollback. Canary shifts traffic gradually (1% → 10% → 50% → 100%), limiting blast radius. Blue-green is simpler; canary gives earlier failure signal at the cost of complexity.
Does blue-green work with stateful services?
It works for stateless app tiers cleanly. For stateful services (databases, caches), you either keep state in a shared store both colors point at, or run a careful migration alongside the deploy. Pure blue-green doesn't solve the data problem for free.
How long should I keep the old color around after switching?
Long enough to be confident the new color is healthy under real load , typically hours, sometimes a day. Scale it down or destroy it after, depending on cost sensitivity and your rollback risk appetite.