Blue-Green Deployment:

 

Blue-Green Deployment: Zero-Downtime Deployments Explained

📅 Published: July 2026
⏱️ Estimated Reading Time: 20 minutes
🏷️ Tags: Blue-Green Deployment, Zero-Downtime, DevOps, Deployment Strategies, Kubernetes, AWS

---

Introduction: The Deployment Problem

Every time you deploy new code, you risk breaking your application. Users might see errors, experience downtime, or lose their session. The bigger the deployment, the bigger the risk.

Traditional deployment strategies try to minimize this risk through scheduled maintenance windows, but these still cause downtime and frustrate users.

Blue-Green deployment solves this problem by eliminating downtime entirely. You deploy the new version alongside the old version, test it in production, then switch traffic over when you're confident it works.

Why Blue-Green matters:

• Zero downtime for users

• Instant rollback (switch back to the old version)

• Ability to test in production before going live

• Reduced deployment risk

• No complex rollback procedures

---

Part 1: What is Blue-Green Deployment?

Blue-Green deployment is a strategy where you maintain two identical production environments, one active (Blue) and one idle (Green).

text

┌─────────────────────────────────────────────────────────────────┐
│                    Before Deployment                            │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Load Balancer                        │   │
│   │                     100% Traffic                        │   │
│   └──────────────────────────┬──────────────────────────────┘   │
│                              │                                   │
│                              ▼                                   │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Blue (Live)                          │   │
│   │                   Version 1.0                           │   │
│   └─────────────────────────────────────────────────────────┘   │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Green (Idle)                         │   │
│   │                   Version 1.0                           │   │
│   └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                    After Deployment                             │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Load Balancer                        │   │
│   │                     100% Traffic                        │   │
│   └──────────────────────────┬──────────────────────────────┘   │
│                              │                                   │
│                              ▼                                   │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Blue (Idle)                          │   │
│   │                   Version 1.0                           │   │
│   └─────────────────────────────────────────────────────────┘   │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    Green (Live)                         │   │
│   │                   Version 2.0                           │   │
│   └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

The workflow is simple:

1. Blue is live (serving all traffic)

2. Deploy new version to Green (no traffic yet)

3. Test Green (in production, but not serving users)

4. Switch traffic to Green (Blue becomes idle)

5. If problems occur, switch back to Blue (instant rollback)

6. Once stable, Blue can be updated to the next version

Key insight: You're not deploying to production. You're deploying to an idle environment, then cutting over.

---

Part 2: Why Blue-Green Works

Zero Downtime

Users never experience an outage. Traffic switches from Blue to Green in a single moment (or gradually if using weighted routing). There is no period where no environment is serving traffic.

The user experience:

• 9:00 AM: User on Blue (Version 1.0)

• 9:05 AM: Traffic switches to Green (Version 2.0)

• 9:06 AM: User session continues seamlessly

Instant Rollback

Deploying new code is easy. Rolling back should be just as easy.

With Blue-Green, rollback is a single switch:

1. Something goes wrong with Green (Version 2.0)

2. Switch traffic back to Blue (Version 1.0)

3. Users are back on the stable version in seconds

No complex rollback procedures. No rebuilding. No database rollbacks (if schema changes are backward compatible).

Production Testing

Green is running in production, with real data, real dependencies, and real infrastructure. You can test it exactly like production—because it is production—without affecting users.

What you can test in Green:

• Performance under load (use partial traffic routing)

• Database migration (with backward compatibility)

• Integration with external services

• UI and user flows

---

Part 3: Blue-Green in Different Platforms

AWS (Using Elastic Beanstalk)

AWS Elastic Beanstalk has built-in Blue-Green deployment.

yaml

# .elasticbeanstalk/config.yml
environment:
  BlueEnv:
    Name: myapp-blue
    Version: app-v1.0.zip
    CNAME: blue.myapp.com
  GreenEnv:
    Name: myapp-green
    Version: app-v2.0.zip
    CNAME: green.myapp.com

Swap CNAMEs to switch traffic:

bash

# Swap environments
aws elasticbeanstalk swap-environment-cnames \
  --source-environment-id blue-env-id \
  --destination-environment-id green-env-id

AWS (Manual with EC2)

For EC2-based deployments:

hcl

# Two Auto Scaling Groups
resource "aws_autoscaling_group" "blue" {
  name = "blue-asg"
  launch_template { id = aws_launch_template.blue.id }
  # ... configuration
}

resource "aws_autoscaling_group" "green" {
  name = "green-asg"
  launch_template { id = aws_launch_template.green.id }
  # ... configuration
}

# Target Groups
resource "aws_lb_target_group" "blue" {
  name = "blue-tg"
  # ... configuration
}

resource "aws_lb_target_group" "green" {
  name = "green-tg"
  # ... configuration
}

# Listener Rule for Routing
resource "aws_lb_listener_rule" "blue" {
  listener_arn = aws_lb_listener.main.arn
  action {
    type = "forward"
    target_group_arn = aws_lb_target_group.blue.arn
  }
}

resource "aws_lb_listener_rule" "green" {
  listener_arn = aws_lb_listener.main.arn
  action {
    type = "forward"
    target_group_arn = aws_lb_target_group.green.arn
  }
}

Kubernetes

In Kubernetes, Blue-Green is implemented using Services and Deployments:

Blue Deployment:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:v1
        ports:
        - containerPort: 8080

Green Deployment:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:v2
        ports:
        - containerPort: 8080

Service (Always points to Blue or Green):

yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue   # Switched to green during deployment
  ports:
  - port: 80
    targetPort: 8080

Switch traffic:

bash

# Change Service selector from blue to green
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

---

Part 4: Blue-Green vs Other Strategies

Strategy	Downtime	Rollback Speed	Complexity
Blue-Green	Zero	Instant	Medium
Rolling Update	Zero (gradual)	Gradual	Low
Canary	Zero	Gradual	High
Recreate	Yes (all old, then new)	Slow	Low
A/B Testing	Zero	User-based	Medium

Blue-Green vs Rolling Update

Aspect	Blue-Green	Rolling Update
Downtime	None	None (if configured properly)
Rollback	Instant (switch back)	Gradual (reverses update)
Testing in production	Yes (on Green before switch)	No (all traffic sees new version)
Infrastructure cost	Double (two environments)	Same (one environment)
Database schema	Must be backward compatible	Must be backward compatible

When to use Blue-Green:

• You need instant rollback capability

• You want to test in production before going live

• You have the infrastructure budget for two environments

• Your database changes are backward compatible

When to use Rolling Update:

• You want zero downtime

• You have limited infrastructure resources

• Your rollback tolerance is acceptable

• You want a simpler deployment process

---

Part 5: Handling Database Changes

The biggest challenge with Blue-Green is database changes.

When you switch from Blue to Green, both environments need to work with the same database. New code (Green) must be backward compatible with the existing database schema.

Backward Compatible Migrations

Rule: Add, don't remove or rename.

• ✅ Add new columns and tables (Green can use them, Blue ignores them)

• ❌ Rename columns (Green expects new name, Blue expects old name)

• ❌ Delete columns (Green doesn't need them, Blue still does)

• ❌ Change column types (may break both environments)

Example:

sql

-- ✅ Safe for Blue-Green
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT false;

-- ❌ Unsafe for Blue-Green (Blue can't see this column)
ALTER TABLE users RENAME COLUMN full_name TO display_name;

Phase 1: Add New Columns (Both Versions Work)

sql

ALTER TABLE users ADD COLUMN display_name VARCHAR(255);

Blue (old code) ignores display_name. Green (new code) uses it. Both work.

Phase 2: Deploy Green

Switch traffic to Green. Both versions can still use the same database.

Phase 3: Remove Old Code (Optional)

Once Green is stable, you can deploy a cleanup migration:

sql

-- Now that Blue is no longer running, we can remove old columns
ALTER TABLE users DROP COLUMN full_name;

---

Part 6: Blue-Green with CI/CD (GitHub Actions)

yaml

name: Blue-Green Deployment

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # 1. Build new image
      - name: Build Docker image
        run: docker build -t myapp:new .

      # 2. Deploy to Green environment
      - name: Deploy to Green
        run: |
          kubectl set image deployment/app-green app=myapp:new
          kubectl rollout status deployment/app-green

      # 3. Test Green (in production!)
      - name: Test Green
        run: ./test-green.sh

      # 4. Switch traffic to Green
      - name: Switch to Green
        run: kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'

      # 5. Wait for confirmation
      - name: Wait for stable
        run: sleep 60

      # 6. Rollback if needed (manual or automatic)
      - name: Health check
        run: curl -f https://myapp.com/health

---

Part 7: Blue-Green with Argo CD

yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-blue
spec:
  source:
    repoURL: https://github.com/org/myapp.git
    path: manifests/blue
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-green
spec:
  source:
    repoURL: https://github.com/org/myapp.git
    path: manifests/green
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true

bash

# Switch traffic by updating Service selector
argocd app patch myapp-service --patch '{"spec":{"selector":{"version":"green"}}}'

---

Blue-Green Checklist

Pre-Deployment

• Database changes are backward compatible

• Both Blue and Green environments exist

• Service points to Blue environment

• Green environment is idle (no traffic)

During Deployment

• Deploy new version to Green environment

• Run integration tests against Green

• Switch traffic to Green

• Verify Green is healthy

• Rollback if issues are detected

Post-Deployment

• Wait for stabilization period

• Keep Blue environment for rollback

• Update Blue environment for next deployment

---

Summary

Aspect	Blue-Green
Downtime	Zero
Rollback	Instant (switch back)
Testing	Production testing on Green
Cost	Double infrastructure
Database	Backward-compatible schemas
Complexity	Medium

Blue-Green deployment is one of the most reliable deployment strategies. Zero downtime, instant rollback, and the ability to test in production make it ideal for mission-critical applications.

---

Learn More

Practice Blue-Green deployments with hands-on exercises in our interactive labs:
https://devops.trainwithsky.com