Blue-Green Deployment
Run two full production environments, switch traffic between them.
StarterPlatform
A new version is deployed in full to the idle (green) environment while the current (blue) one keeps serving traffic. Once green passes checks, the router switches all traffic over instantly, and blue stays warm as an instant rollback target.
When to use it
- Deployments need a near-instant, low-risk rollback path
- You can afford to run two full-size environments, even briefly
Trade-offs
- Doubles infrastructure cost for the duration of the switch
- Database schema changes must stay compatible with both versions during the cutover
Components used
Load BalancerContainer ServiceCI/CD Pipeline
How it works
- Two complete production environments exist. One serves live traffic while the other sits idle at the new version.
- The new version is deployed and verified on the idle environment, then a router or load balancer flips all traffic across in one step.
- The previous environment is kept warm, so rollback is another flip rather than a redeploy.
Used in the wild
- Releases that must be all-or-nothing, where mixed versions would corrupt data.
- Environments where rollback speed matters more than infrastructure cost.
- Systems with lengthy startup or warm-up times that make in-place restarts painful.
Good to know
- The cutover is instant for new requests but not for the database, which is shared. Schema changes must be backwards compatible with both versions or the flip becomes irreversible.
- You are paying for double the production capacity during the overlap, which is the honest reason many teams choose canary releases instead.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Canary Release
Send a small slice of traffic to the new version before a full rollout.
Feature-Flag Rollout
Ship code dark, then turn features on for cohorts without redeploying.