Blue-Green Deployment

Blue-green deployment runs two identical production environments and switches traffic from the live stack to a prepared one, making releases atomic and rollback fast.

delivery

Definition

Blue-green deployment is a release technique that maintains two identical production environments, blue and green, and routes all traffic to one while the other receives the new version. The switch is a single routing change, so users never see a half-updated fleet.

Context and scope

It suits services that need near-zero downtime and a fast, predictable rollback, and teams willing to pay for duplicated production capacity during the release window.

Common misconceptions

Blue-green means zero downtime at no extra cost — the idle environment still consumes full production resources.
The switch is always instant — long-lived connections, caches, and database migrations can stretch or break the cutover.
Rollback is free — schema changes already applied to a shared database often cannot be undone by switching traffic back.

Anti-patterns

Running different schema versions in the two environments without a backward-compatible migration plan
Sharing one database and mutating it during the green warm-up
Switching traffic before health checks and smoke tests pass on green

Related concepts

Authoritative source

https://martinfowler.com/bliki/BlueGreenDeployment.html

Two environments, one live route

Blue-green deployment runs two identical production stacks. At any moment one, say blue, serves all user traffic while the other, green, receives the new release. Engineers deploy, migrate, and test green while blue keeps serving. When green passes health checks and smoke tests, the router or load balancer flips to it. Because the switch is one routing change rather than a gradual replacement of instances, every user moves to the new version at the same moment.

Users -> load balancer -> blue (v1)   [live]
                       -> green (v2)  [warming up]
Cutover: target group -> green
Rollback: target group -> blue

When it fits

Use blue-green when downtime is expensive, rollback must take seconds, and the team can afford duplicate capacity. It works best for stateless services behind a load balancer. Compare it with rolling deployment, which replaces instances in place and is cheaper but leaves old and new versions serving traffic side by side during the rollout. Blue-green gives a clean version boundary; rolling deployment gives lower cost.

Trade-offs

Duplicating production doubles cost during the release window. Databases are the hard part: both environments usually share one database, so the new version must tolerate the old schema and vice versa. Keep migrations backward compatible for at least one release. Caches, message queues, and long-lived WebSocket connections may need draining or dual-write handling.

A concrete example

A team ships a payments API on Kubernetes. They create a second Deployment and Service, run migrations that only add columns, warm the green pods, then point the Ingress at green. A failing smoke test flips the Ingress back in under a minute. One release later they drop the old columns.

The common myth is that blue-green is free and instant. It is neither: idle capacity costs money, and stateful dependencies decide whether the cutover is truly reversible. Related concepts include rolling deployment and progressive delivery.