Skip to content
SP StackPractices
intermediate By StackPractices

Blue-Green Deployment

Deploy with zero downtime using blue-green environments, instant traffic switching, and automated rollback capabilities.

Topics: devops

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:

  1. Blue environment serves all production traffic
  2. Green environment receives the new deployment
  3. Smoke tests validate green (health checks, synthetic transactions)
  4. Traffic switch routes all users to green
  5. Blue remains warm as instant rollback target
  6. 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

StrategyDowntimeRollback SpeedCost
Blue-GreenZeroInstant (seconds)2x infrastructure
RollingZeroSlow (minutes)1x + surge
CanaryZeroMedium (minutes)1x + small surge
RecreateHighN/A1x

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

  1. Stateful blue/green: Sessions stored in-memory are lost during switches; use Redis or JWT
  2. Different configs: Blue and green must have identical environment variables except the version
  3. Forgetting to test rollback: A deployment that can’t roll back safely is not production-ready
  4. Database schema conflicts: Breaking schema changes deployed before both apps are compatible
  5. 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.