Blue-Green Deployment

Shipping a new version used to mean taking the service down. While the old code was being stripped off the running servers and the new code put in its place, there was no screen to show anyone who arrived. That's where notices like "maintenance from 2am to 4am" came from, and it's why teams sat in the office at those hours.

The real problem wasn't the two hours of downtime. It was what happened afterward. If someone noticed that payments were broken once the new code was live, undoing it meant running another deployment — pulling the old build back out, starting the servers again, thirty more minutes of broken screens. Because backing out was expensive, teams hesitated over ambiguous symptoms. "Let's watch it a bit longer" won more often than it should have, and outages ran long.

Blue-green deployment flips both of those at once. The new code never goes onto the servers currently serving traffic. It goes onto a second, identical environment sitting next to them, empty. Users stay on the old one the whole time, so nothing goes dark. And because the old environment is still running untouched after the switch, backing out is no longer a deployment — it's one configuration change that points traffic back where it came from.

The name comes from the labels: blue is the side currently taking users, green is the idle side that receives the new version. There are five steps.

1. Prepare a second environment the same size as blue. An environment is a separate execution space with its own purpose — development, staging, production — and this one has to match production in both capacity and configuration. Results from a green that runs at half the server count prove nothing about handling real traffic.
2. Deploy the new version to green. At this moment green is a complete, working service that nobody is using. It can take an hour to come up without affecting a single user, so there's no reason to rush this step.
3. Run a smoke test against green only. A smoke test checks just that the essentials are alive, so you walk five or six flows that must never break — sign-in, opening a document, saving, payment — and finish in a couple of minutes. Trying to exercise every feature here delays the switch indefinitely.
4. Repoint the load balancer from blue to green. A load balancer decides which server each incoming request goes to, and the moment that one setting changes, every new request lands on green. The cutover itself takes seconds.
5. Leave blue running instead of tearing it down. Usually until the next release, and at minimum for a few hours. During that window blue is your rollback insurance: if something looks wrong, pointing the load balancer back at blue ends the incident, which turns a thirty-minute recovery into a few seconds.

One trap sits underneath all of this. There are two sets of servers, but usually only one database, because data written on green still has to be readable if you go back to blue. Any change to the shape of a table therefore has to work under both the new code and the old. To rename a column, first ship a release that adds the new column and writes to both; dropping the old column waits for a later release. Skip that sequencing and traffic goes back while the data does not.

It fits services where downtime converts directly into losses. Payments or booking, where two minutes offline produces refunds and support tickets, or products whose users are spread across enough time zones that no hour is quiet. If servers can be added and removed with a single command, as they can on cloud infrastructure, the setup cost is low too.

It also earns its keep during periods when you expect to reverse course. Knowing that backing out is cheap makes the decision faster, so an ambiguous bug report can be answered with "roll back first, investigate after" instead of a debate.

There are three limits. The first is cost. Running two environments of the same size roughly doubles the server bill — a team spending $2,300 a month spends $4,600. You can shrink that by only starting green just before a release and shutting blue down after the switch, but that also throws away the rollback insurance you were paying for.

The second is the database. Traffic returns in seconds; the rows written in between do not. The third is long-running work. A user who was uploading a file on blue at the moment of the cutover loses that upload. Sending only new requests to green while letting in-flight requests finish on blue takes its own configuration, usually a drain period measured in minutes.

"Let's do this one blue-green. We need to be able to back it out immediately."

The change carries enough risk that the team wants the method with the shortest recovery.

"Green is up. I'll cut over once the smoke test passes."

The new environment is ready, and traffic moves after a quick check of the critical flows.

"Blue is still up, right? We're getting payment reports."

Checking whether the option to roll back is still available before anything else.

The day Pagedeck swapped its payment module is the typical shape. Theo brings up green at 3pm, deploys the new version, walks the two critical flows, and repoints the load balancer at 3:12.

At 3:40 Sofia hears from a customer that adding a card fails. Finding the cause will take a while; going back will not. So Theo points traffic at blue first and investigates second. Users saw broken screens for twenty-eight minutes and no longer, and the service runs normally while the cause is tracked down. Under the old model those twenty-eight minutes would have stretched until the fix was found and redeployed.

The most common mistake is believing that blue-green makes anything reversible. Watching the switch take three seconds makes that easy to assume. But only the code goes back. Orders written in the new format during those thirty minutes on green can't be read by the old code on blue, and emails that already went out to customers don't unsend. Teams that relax on this point discover a stranger state after the rollback than they had before it.

Reading "zero downtime" as "the screen never flickers" is the other frequent one. In practice the requests still attached to blue at the moment of the cutover need time to finish, and if nobody designed that handoff, a handful of users see one failure. Zero downtime is a result you get from deciding how in-flight requests are drained, not a property that arrives on its own.