Blue-Green Deployment
Deploy with zero downtime using blue-green environments, instant traffic switching, and automated rollback capabilities.
Note: This guide follows English-language naming conventions and terminology standards common in international development teams. Examples use English identifiers and comments to maximize compatibility across codebases and tooling.
Overview
Blue-green deployment is a release strategy that maintains two identical production environments — one active (blue) and one idle (green). New versions deploy to the idle environment, get smoke-tested, and then traffic switches instantly. If problems arise, rollback is a single traffic switch away, taking seconds instead of hours.
When to Use
Use this resource when:
- Downtime during deployments is unacceptable (SLA > 99.9%)
- You need instant rollback capability without redeploying
- Running database migrations that must be backward-compatible
- Validating new releases against real production traffic via canary routing
Solution
Nginx Traffic Switch (Bash)
#!/bin/bash
# Switch traffic from blue to green
BLUE_IP="10.0.1.10"
GREEN_IP="10.0.1.11"
NGINX_CONF="/etc/nginx/sites-enabled/app"
# Update upstream to point to green
sed -i "s/server $BLUE_IP:8080/server $GREEN_IP:8080/" $NGINX_CONF
nginx -s reload
# Health check on green
if ! curl -sf http://$GREEN_IP:8080/health; then
# Rollback instantly
sed -i "s/server $GREEN_IP:8080/server $BLUE_IP:8080/" $NGINX_CONF
nginx -s reload
echo "Rollback complete"
exit 1
fi
Kubernetes Deployment with Service Switch
apiVersion: v1
kind: Service
metadata:
name: app-active
spec:
selector:
version: blue # Change to "green" to switch
ports:
- port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
spec:
replicas: 3
selector:
matchLabels:
app: web
version: green
template:
metadata:
labels:
app: web
version: green
spec:
containers:
- name: app
image: myapp:v2.0.0
AWS Route 53 Weighted Routing
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890 \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"SetIdentifier": "green",
"Weight": 100,
"TTL": 60,
"ResourceRecords": [{"Value": "1.2.3.4"}]
}
}]
}'
Explanation
How it works:
- Blue environment serves all production traffic
- Green environment receives the new deployment
- Smoke tests validate green (health checks, synthetic transactions)
- Traffic switch routes all users to green
- Blue remains warm as instant rollback target
- Next deploy goes to blue, roles swap
Database compatibility:
- Migrations must be backward-compatible (add columns, never remove)
- Blue must tolerate green’s schema; green must tolerate blue’s schema
- Use feature flags to hide new columns from blue
Variants
| Strategy | Downtime | Rollback Speed | Cost |
|---|---|---|---|
| Blue-Green | Zero | Instant (seconds) | 2x infrastructure |
| Rolling | Zero | Slow (minutes) | 1x + surge |
| Canary | Zero | Medium (minutes) | 1x + small surge |
| Recreate | High | N/A | 1x |
Best Practices
- Keep blue warm for one deploy cycle: Don’t decommission until the next deployment succeeds
- Automate the switch: Manual DNS updates are error-prone; use CI/CD pipelines
- Monitor during switch: Watch error rates, latency, and business metrics for 5-10 minutes post-switch
- Use sticky sessions carefully: Switching mid-session can disrupt stateful connections
- Share state via external stores: Both environments must access the same databases, caches, and queues
Common Mistakes
- Stateful blue/green: Sessions stored in-memory are lost during switches; use Redis or JWT
- Different configs: Blue and green must have identical environment variables except the version
- Forgetting to test rollback: A deployment that can’t roll back safely is not production-ready
- Database schema conflicts: Breaking schema changes deployed before both apps are compatible
- Leaving old environments running: Unused environments incur cloud costs; automate cleanup
Frequently Asked Questions
Q: How much does blue-green cost? A: Roughly double during deploy windows. You can scale down blue to minimal instances between deploys.
Q: Can I use blue-green with serverless? A: Yes. AWS Lambda aliases, API Gateway canary stages, and Vercel production/preview deployments all support it.
Q: What’s the difference between blue-green and canary? A: Blue-green switches 100% of traffic at once. Canary routes a small percentage first, then gradually increases.
Related Resources
Blue-Green and Canary Deployments
A practical guide to deployment strategies: blue-green, canary, rolling, and feature flags. Minimize risk and rollback time when releasing to production.
DocPost-Deployment Verification Checklist Template
A checklist template for verifying deployments: health checks, smoke tests, metric validation, and rollback readiness before declaring all-clear.
GuideCI/CD Pipeline Guide
A practical guide to building CI/CD pipelines with GitHub Actions, testing, deployment strategies, and rollback procedures.
RecipeImplement Graceful Shutdown and Zero-Downtime Restarts
How to implement graceful shutdown and zero-downtime restarts for web servers, workers, and containers
RecipeCanary Deployments with Istio Service Mesh
How to use Istio traffic splitting to perform safe canary deployments by gradually shifting user traffic between application versions