Blue-Green Deployments
Blue-green deployment is a release strategy that maintains two identical, fully provisioned production environments — conventionally labeled 'blue' and 'green' — where only one serves live traffic at any given time. When a new version is ready to ship, it is deployed in full to the idle environment (say, green, while blue currently serves users), tested against production-like conditions without any customer exposure, and then traffic is switched from blue to green atomically, typically at the load balancer or router level. If anything goes wrong post-switch, traffic can be routed back to blue in seconds, since the previous version is still fully running and warm, not merely archived somewhere. This makes blue-green one of the fastest rollback strategies among deployment patterns.
Cricket analogy: Think of a team having two full XIs ready — one batting live while the other trains in the nets on identical conditions; when the coach swaps lineups at the toss, the bench XI steps in instantly, and if it flops, the original XI is still padded up to return next over.
How the Traffic Switch Works
The switch itself is typically implemented at a layer that can redirect all traffic instantly: updating a load balancer's target group, flipping a DNS record (though DNS carries propagation delay and caching risk, making it a weaker choice), or changing a Kubernetes Service's selector to point at a different set of pod labels. Because the cutover is a single atomic operation rather than a gradual rollout, blue-green trades off the ability to limit exposure to a subset of users — everyone moves to the new version simultaneously — in exchange for simplicity and an extremely fast, clean rollback path.
Cricket analogy: Changing the batting order via the toss coin rather than sending a runner mid-over is like flipping a Kubernetes Service selector — instant and clean — whereas relying on a slow radio announcement to change the order is like DNS, delayed and unevenly received by different parts of the ground.
Cost and State Considerations
Running two full production environments simultaneously, even briefly, roughly doubles infrastructure cost for the duration of the overlap, which is the primary tradeoff against blue-green's simplicity and safety. Stateful components complicate the pattern further: if both environments share a single database, schema migrations must be backward-compatible with both the old and new application versions during the cutover window, since blue may still receive traffic (or need to be rolled back to) after green's version has already written data in a new format. Teams often mitigate this with expand-contract migration patterns that add new columns/tables in a release before removing old ones in a later release.
Cricket analogy: Fielding two full XIs on payroll simultaneously roughly doubles the wage bill for as long as the overlap lasts, and if both squads share the same physio and equipment room, new kit must still fit players from either squad during the transition, much like schema changes needing to work for both app versions.
# Kubernetes Service selector flip implements the blue-green traffic switch
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
selector:
app: api
version: green # was 'blue' before cutover; change + apply to switch instantly
ports:
- port: 80
targetPort: 8080
---
# CI pipeline step performing the cutover after health checks pass
# deploy-green-then-switch.yml
jobs:
cutover:
steps:
- name: Deploy green environment
run: kubectl apply -f k8s/deployment-green.yaml
- name: Wait for green to be healthy
run: kubectl rollout status deployment/api-green --timeout=120s
- name: Run smoke tests against green (internal endpoint)
run: ./scripts/smoke-test.sh https://green.internal.acme.com
- name: Switch traffic to green
run: kubectl patch service api-service -p '{"spec":{"selector":{"version":"green"}}}'Blue-green is often compared to changing a stage set behind the curtain: the audience (users) never sees the new set being built, and when the curtain rises the switch is instantaneous. If the new act flops, the curtain can drop and reopen on the old set just as fast.
A common misconception is that blue-green deployment alone provides gradual, risk-limited rollout — it doesn't. Because the traffic cutover is atomic and all-or-nothing, a bug in the new version affects 100% of users the instant the switch happens, unlike canary releases which intentionally expose only a small percentage first. Blue-green's safety comes from fast rollback, not reduced blast radius during rollout.
- Blue-green deployment runs two full, identical environments and switches all traffic between them atomically.
- Rollback is extremely fast because the previous environment stays fully running and warm, not archived.
- The traffic switch is best implemented at the load balancer or service-selector level, not via DNS, to avoid propagation delay.
- Running two environments simultaneously roughly doubles infrastructure cost during the overlap window.
- Shared databases require backward-compatible schema migrations (expand-contract pattern) across both versions.
- Blue-green does not limit blast radius during rollout — it is all-or-nothing, unlike canary releases.
Practice what you learned
1. What is the defining characteristic of a blue-green deployment?
2. Why is blue-green rollback typically much faster than redeploying a previous version from scratch?
3. Why is DNS often considered a weaker mechanism for implementing the blue-green traffic switch compared to a load balancer?
4. What is a major cost tradeoff of blue-green deployment?
5. What is a common misconception about blue-green deployment's risk profile?
Was this page helpful?
You May Also Like
Canary Releases
Learn how canary releases gradually expose a small percentage of real traffic to a new version, using metrics to decide whether to expand or abort the rollout.
Rolling Deployments
Rolling deployments replace instances of an application gradually, batch by batch, so the service stays available throughout the release without needing a full duplicate environment.
Deploying Containers from CI/CD
Learn the common patterns pipelines use to deploy containerized applications, from direct kubectl updates to GitOps-driven reconciliation.
Rollback and Incident Response in CI/CD
Learn how to design pipelines that can quickly and safely revert a bad deployment, and how rollback strategy fits into a broader incident response process.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics