Blue-Green Deployment

Blue-green deployment runs two production environments, “as identical as possible,” with only one serving traffic at a time. You deploy and finish testing on the idle one, then move all traffic to it. The problem it solves is stated narrowly: “one of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. You usually need to do this quickly in order to minimize downtime.”

The mechanics are simple enough to state in full. “As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment — the blue one is now idle.” And the headline benefit: it “gives you a rapid way to rollback — if anything goes wrong you switch the router back to your blue environment.”

The environments then swap roles rather than one being permanently secondary: “you then use the blue environment as your staging environment for the final testing step for your next deployment,” switching back when the next release is ready. “That way both green and blue environments are regularly cycling between live, previous version (for rollback) and staging the next version.”

What it gives you, and what it does not

One benefit is easy to miss and worth collecting deliberately. Because the arrangement is “the same basic mechanism as you need to get a hot-standby working,” it “allows you to test your disaster-recovery procedure on every release” — with the wry qualification, “I hope that you release more frequently than you have a disaster.” A team that switches environments every week has rehearsed its failover weekly without scheduling a drill.

What it does not give you is a true undo, and the source says so directly: “there’s still the issue of dealing with missed transactions while the green environment was live.” Switching the router back does not retract anything the new version wrote — orders placed, emails sent, rows updated. Two mitigations are offered, both requiring design in advance: feeding transactions to both environments “in such a way as to keep the blue environment as a backup when the green is live,” or putting “the application in read-only mode before cut-over, run it for a while in read-only mode, and then switch it to read-write mode.”

Which leads to the question to settle before adopting it, because a fast switch is worth little if the state has moved on.

• Sessions. What happens to users mid-session when traffic moves? Shared or externalized session state makes this a non-event; in-memory session state makes the cutover visible to everyone logged in.
• Work in flight. Long-running requests, background jobs, and consumers with uncommitted positions do not stop because the router changed. Either they drain before the switch or they are designed to be interrupted.
• Shared state. Whatever both environments write to is the thing that cannot be switched back — normally the database, and often a message broker or a cache.

The database is the whole difficulty

The source is candid that this is where the technique gets hard: “databases can often be a challenge with this technique, particularly when you need to change the schema to support a new version of the software.” A common variation keeps one database and applies blue-green only to the layers above — “another variation would be to use the same database, making the blue-green switches for web and domain layers” — which makes the shared schema the single thing both versions must tolerate.

The prescribed answer is to sequence the change so a reversal point exists: “the trick is to separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support both the new and old version of the application, deploy that, check everything is working fine so you have a rollback point, then deploy the new version of the application. (And when the upgrade has bedded down remove the database support for the old version.)”

That is expand and contract stated for schemas, and it is the precondition that makes the router switch meaningful. Skip it and the second half of the promise disappears: the traffic switch still takes seconds, and the previous version no longer starts. Fast reversal of the application is not reversal of the system.

Compared with a canary, and what to run

Blue-green and canary deployment are often presented as alternatives, and they answer different questions. Blue-green switches everything at once and optimizes for how quickly you can change your mind. A canary exposes a limited share of real traffic and optimizes for learning before the blast radius grows. So blue-green tells you nothing about how the new version behaves under partial load, and a canary does not give you a one-action reversal of the whole estate.

The two combine well and the combination is common in practice: route a small share of traffic to the new environment first, then move the rest and keep the old one warm as the reversal target. What is not optional in either case is the compatibility work, since both rely on old and new coexisting.

On cost: the implementations vary more than the name suggests. The environments “can be different pieces of hardware, or… different virtual machines running on the same (or different) hardware,” or “a single operating environment partitioned into separate zones with separate IP addresses for the two slices.” And the switch itself need not be a router — “one project did the switch by bouncing the web server.” The stated principle is deliberately loose: “the fundamental idea is to have two easily switchable environments to switch between, there are plenty of ways to vary the details.” Where the duplication is genuinely expensive, that principle is what to hold onto rather than the literal two-environment picture.

Reversal here is rollback with a fast mechanism attached, and it carries the same precondition: the previous version has to be able to run against current data. How that precondition gets designed, and what to do when it fails, is worked through in Two Versions at Once.

Reference: Martin Fowler, Blue Green Deployment, martinfowler.com (2010, updated 2015; checked September 2026).