Blue-Green Deployments Explained
Blue-green keeps two identical environments and flips traffic between them.
A blue-green deployment runs two production-grade environments side by side. One serves live traffic while you deploy and test the other, then you switch a single router. This lesson explains the mechanics, the cost, and how it enables instant rollback.
The two environments
Call the live environment "blue" and the idle one "green". You deploy the new version to green, run smoke tests against it while no users touch it, then repoint the load balancer or DNS from blue to green. Blue becomes the new idle standby.
Why teams use it
- The cutover is instant and atomic - all traffic moves at once.
- Rollback is just flipping traffic back to the still-running old environment.
- You can fully validate the new version before any user reaches it.
The cost and the catch
You temporarily run double the capacity, which costs more. Stateful components are the hard part: shared databases must be compatible with both versions, and long-lived connections need draining. Plan how in-flight sessions and the database are handled before the switch.
Switching traffic
The switch is typically a load balancer target change. Conceptually:
# point the production listener at the green target group
aws elbv2 modify-listener \
--listener-arn $LISTENER_ARN \
--default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARNKey takeaways
- Blue-green runs two environments and switches traffic in one atomic step.
- Rollback is near-instant because the old environment stays running.
- It costs double capacity and requires database compatibility across versions.