Blue-Green Deployment

Updated September 30, 20262 min read

In short

Blue-green deployment is a release strategy that uses two identical production environments and moves all traffic from the old version to the new one at once.

What is a blue-green deployment?

A blue-green deployment uses two identical production environments, traditionally called blue and green. At any moment, one of them, say blue, serves all live traffic, while the other is idle or kept on standby. To release a new version, you deploy it to the idle green environment, test it there on real production infrastructure without real users, and then switch traffic over.

The switch usually happens at a load balancer or router, or through a DNS change, so it takes only seconds and users see no downtime. If something goes wrong after the switch, rolling back is just as fast: point traffic back to blue, which is still running the old version. Once the new version has proven stable, blue becomes the idle environment for the next release.

It is like a theater with two stages: while the audience watches the show on one stage, the crew builds and rehearses the next set on the other, and then the lights shift to the new stage in an instant. The main costs are running two full environments during a release and handling shared state carefully, especially database schema changes, which must work with both the old and the new version at the same time.

Blue-green deployment is often confused with canary releases and rolling updates. A canary release sends a small percentage of users to the new version first and increases it gradually, while a rolling update replaces servers or pods a few at a time, which is the default in Kubernetes. Blue-green switches everyone at once but keeps the old environment ready for an instant rollback.

Key takeaways

Two identical environments exist: one live, one idle.
The new version is deployed and tested on the idle environment before going live.
Traffic switches all at once, typically at the load balancer, with no downtime.
Rollback is fast because the old environment keeps running.
Database changes must stay compatible with both versions during the switch.

Example

Switching traffic from blue to green in Kubernetesbash

# Deploy the new version next to the old one (its pods are labeled version=green)
kubectl apply -f web-green.yaml

# Wait until the green pods are ready before switching
kubectl rollout status deployment/web-green

# Switch live traffic by pointing the Service at the green pods
kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"green"}}}'

# Roll back instantly, if needed, by pointing it at blue again
kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"blue"}}}'

Readers ask

What is the difference between blue-green and canary deployment?

Blue-green deployment moves all traffic from the old version to the new one in a single switch. A canary deployment sends a small share of traffic to the new version first and increases it gradually while watching error rates and performance.

How do you handle the database in a blue-green deployment?

Both environments usually share one database, so schema changes must be backward compatible with the old version. A common approach is expand and contract: first add new columns or tables without removing anything, deploy the new code, and remove old structures only in a later release.

Does blue-green deployment cost more?

It can, because two full production environments run at the same time during a release. With cloud infrastructure and containers, the idle environment can be created just before a release and removed afterward to limit the extra cost.

Often compared

Blue-Green vs Canary DeploymentBlue-green runs two full environments and switches all traffic to the new one at once, while canary sends a small share to the new version first and grows it.