What Is Blue-Green Deployment?

What Is Blue-Green Deployment?

Blue-green deployment is a release strategy that reduces downtime and risk by running two identical production environments.

How It Works

You maintain two production environments:

• Blue — the current live environment serving real traffic
• Green — the idle environment where you deploy the new version

The deployment flow:

1. Deploy the new version to the Green environment
2. Run smoke tests and health checks against Green
3. Switch the load balancer to point traffic from Blue to Green
4. Green becomes the new live environment
5. Blue becomes idle (available for instant rollback)

Key Benefits

• Zero-downtime deployments — users experience no interruption
• Instant rollback — switch traffic back to Blue if issues arise
• Production testing — test the new version in a real environment before switching
• Reduced deployment anxiety — safe rollback eliminates fear of shipping

Implementation Example

# AWS ALB target group switching
aws elbv2 modify-listener \
  --listener-arn $LISTENER_ARN \
  --default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARN

With Kubernetes:

apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    app: myapp
    version: green  # Switch to 'blue' for rollback

Challenges

• Database migrations — schema changes must be backward-compatible since both versions may run simultaneously during the switch
• Double infrastructure cost — you need two complete environments
• Session management — user sessions must survive the switchover
• Cache warming — the new environment starts with cold caches

When to Use Blue-Green

• Applications requiring zero-downtime deployments
• Services where rollback speed is critical
• When you can afford the extra infrastructure cost

Monitoring the Switch

After switching to Green, monitor error rates closely. Tools like Bugsly show you immediately if the new version introduces errors that weren't caught in testing. If error rates spike, switch back to Blue while you investigate.

Alternatives

• Canary deployments — gradually shift traffic (lower risk, slower rollout)
• Rolling deployments — update instances one at a time (less infrastructure, no instant rollback)