Blue-green deployment
Also known as: blue/green deployment, red-black deployment, blue-green release
Blue-green deployment keeps two identical production environments, 'blue' and 'green.' One serves users while the new version is installed and tested on the other; then traffic switches over in one step.
If something breaks, you switch back. While it offers some of the fastest rollbacks available, it doubles infrastructure during releases and does nothing to protect you from a bad database change.
Blue-green deployment, explained at three levels
At home
Imagine a restaurant with two identical kitchens. While one serves dinner, the other is set up with a new menu. When it's ready, waiters start taking orders to the new kitchen. If the new dishes go wrong, they go back to the old one.
At work
Blue-green deployment reduces downtime during updates. Customers keep using the current version while the new one is prepared, and the switch takes seconds. Rolling back is just as fast.
At home
The switch usually happens at a load balancer or DNS setting that decides which environment receives traffic. Nothing about the old environment changes, so it's ready to take traffic back immediately.
At work
Blue-green works best for stateless application tiers. Before switching, teams run smoke tests against the idle environment. After switching, the old environment stays up for a while as a rollback option, then becomes the target for the next release.
At home
The tricky part is anything both environments share, like a database. If the new version changes the database in a way the old version can't handle, switching back won't help. In my opinion, that's where most blue-green plans quietly fall apart.
At work
Handle shared state with backward-compatible 'expand and contract' migrations: add new columns first, deploy code that works with both, and remove old structures in a later release. Consider long-lived connections, caches, and background jobs during the cutover. Weigh the cost of duplicate environments against canary releases, which need less spare capacity.
Real-world examples
At home
Thomas ran a small online store and dreaded updates that took his site down. His hosting provider offered blue-green deployments, so now he tests each update on the idle copy and switches over during his lunch break.
At work
Carlos is a release manager at a Quebec government services portal. With blue-green deployment, his team switched to a new version at 6 a.m., found a login bug at 6:05, and switched back by 6:06, before most citizens noticed.
How it compares
| feature | Blue-green deployment | Rolling deployment |
|---|---|---|
| Switch style | All traffic at once | Servers updated one batch at a time |
| Rollback speed | Seconds | Slower, reverse the roll |
| Extra capacity | A full second environment | Little or none |
| Mixed versions | No, one version at a time | Yes, during the rollout |
Blue-green buys instant rollback with extra infrastructure.
For analysts
Blue-green is easy to approve and hard to do well when data is involved. I'd ask the team to explain how a rollback works if the database has changed, because that answer tells you whether the safety net is real.
History & origin
The technique came out of work at ThoughtWorks in the mid-2000s and was popularized by Jez Humble and David Farley's 2010 book Continuous Delivery and a Martin Fowler article that same year. Cloud computing made it practical for more teams, because spinning up a second environment no longer meant buying a second set of servers. Cloud services such as AWS Elastic Beanstalk and CodeDeploy built blue-green switching into their tooling. In my view, blue-green is the most intuitive release strategy to explain to non-technical stakeholders: there's an old house and a new house, and you just move the front door.