What is a blue-green deployment?
How it works
You run two production-like environments, blue and green. At any time, one is live (receiving user traffic) and the other is idle. When you want to release, you deploy the new version to the idle environment, run tests, then switch the router or load balancer to point to it.
This gives near-zero downtime and instant rollback: if something goes wrong, switch traffic back to the old environment. The old environment stays warm until you're confident, then you can reuse it for the next release.
- Two environments with identical infrastructure.
- Deploy to the idle one, test, then flip the switch.
- Rollback by flipping back.
- Requires double the resources (or careful scaling).
When to use it
Blue-green works well for stateless web apps and APIs where you can run two copies. It's less suitable for stateful systems (databases) unless you handle schema changes carefully. Many cloud providers offer blue-green via services like AWS Elastic Beanstalk or Kubernetes with two Deployments and a Service selector.
Compared to canary releases, blue-green is all-or-nothing: all traffic switches at once. Canary sends a small percentage first, which is safer for catching issues but slower to roll out.
Common mistakes
- Forgetting that database schema changes must be backward-compatible with both versions during the switch.
- Not keeping the old environment running long enough to roll back quickly.
- Assuming blue-green is free; you pay for double the infrastructure during the switch.
