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
Think of a restaurant with two identical kitchens. One serves tonight's dinner while the other is set up with a new menu. When the new kitchen is ready, waiters start sending orders there instead. If the new dishes go wrong, they simply send orders back to the old kitchen, which never stopped working. Blue-green deployment does the same with two copies of a software system.
At work
Blue-green deployment keeps two identical production environments. One, say blue, serves customers while the new version is installed and tested on green. When green is ready, all traffic switches over at once. If problems appear, traffic switches back to blue in seconds. Businesses care because updates cause little or no downtime and rollbacks are nearly instant, at the cost of running duplicate infrastructure.
At home
The two environments sit behind a single switch, usually a load balancer or a DNS record that decides where visitors are sent. While blue serves visitors, green gets the new version and a round of checks. Flipping the switch sends all new visitors to green. Blue stays untouched and running, so flipping back is just as quick. After a quiet period, blue becomes the place where the next update gets installed.
At work
A typical release has four steps: deploy the new version to the idle environment, run smoke tests against it, switch the router, and keep the old environment warm as a rollback target. In AWS this might mean swapping load balancer target groups; in Kubernetes, changing which deployment a service points to. Blue-green suits stateless application tiers best. Sessions, long-lived connections, and background jobs need draining or careful handover during the switch.
At home
The weak spot is anything both environments share, usually the database. Blue and green have separate application servers but often read and write the same data. If the new version changes the database in a way the old version can't understand, switching back no longer helps. While the switch itself is instant and safe, in my opinion shared data is where most blue-green plans quietly fall apart.
At work
Shared state is handled with expand-and-contract migrations: first add new columns or tables, then deploy code that works with both shapes, and only remove old structures in a later release, so either environment can serve traffic at any point. Plan for DNS caching delays, connection draining, and queue consumers that may process messages twice during cutover. Compared with canary releases, blue-green doubles capacity during releases but gives a cleaner, all-or-nothing switch.
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.