What is Blue-Green Deployment? Explained Simply for Beginners (2026)

Blue-green deployment lets you release new code with zero downtime and instant rollback. Here's exactly how it works, how it differs from rolling updates and canary, and how to implement it in Kubernetes and AWS.

Deploying new code is risky. Something can always go wrong — a bug, a performance regression, a database migration that breaks something. Blue-green deployment is a technique that lets you release new versions with zero downtime and instant rollback.

Here's exactly how it works.

The Problem: Risky Deployments

Traditional deployment: you take down the old version, deploy the new version. During the switch, your site is down. If something breaks, rolling back means another round of downtime.

This is called a disruptive deployment. Even "rolling updates" have a window where old and new code run simultaneously — which can cause problems if they're incompatible.

The Blue-Green Idea

Keep two identical production environments:

Blue = current live version (serving all traffic)
Green = new version (deployed and tested, but not live yet)

Users → Load Balancer → [ BLUE  ] ← Live (v1.0)
                         [ GREEN ] ← New version (v2.0) being tested

When you're ready to release:

Switch the load balancer to point to Green
Green is now live. Blue is idle.

Users → Load Balancer → [ BLUE  ] ← Now idle (v1.0)
                      ↗ [ GREEN ] ← Now live (v2.0)

If something breaks:

Switch load balancer back to Blue (takes seconds)

That's it. Blue is your instant rollback. No redeployment needed.

Blue-Green vs Rolling Update vs Canary

Strategy	How it works	Downtime	Rollback speed	Risk
Recreate	Stop old, start new	Yes	Slow	High
Rolling Update	Replace pods gradually	No	Moderate	Medium
Blue-Green	Switch traffic instantly	No	Instant	Low
Canary	Route small % to new version	No	Instant	Lowest

Blue-green is best when:

You need instant rollback capability
Your new and old versions cannot run simultaneously (breaking changes)
You want to test the new version on production infrastructure before going live

Canary is better when:

You want to test with a small % of real users
You can afford gradual rollout (hours/days)
Your services are stateless and can run mixed versions

How Blue-Green Works in Kubernetes

Kubernetes doesn't have a built-in blue-green feature, but you can implement it using labels and Services.

Step 1: Deploy Blue (current production)

yaml

# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-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: myapp
        image: myapp:v1.0
        ports:
        - containerPort: 3000

Step 2: Service Points to Blue

yaml

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: blue   # ← Traffic goes to blue pods
  ports:
  - port: 80
    targetPort: 3000

Step 3: Deploy Green (new version)

yaml

# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-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: myapp
        image: myapp:v2.0   # ← New version
        ports:
        - containerPort: 3000

bash

kubectl apply -f green-deployment.yaml
 
# Wait for green to be fully ready
kubectl rollout status deployment/myapp-green

Step 4: Test Green Before Switching

Test the green deployment before sending real traffic:

bash

# Port-forward directly to green pods (not through the Service)
kubectl port-forward deployment/myapp-green 8080:3000
 
# Run your smoke tests against localhost:8080
curl http://localhost:8080/health
curl http://localhost:8080/api/users

Step 5: Switch Traffic to Green

bash

# Patch the Service selector to point to green
kubectl patch service myapp \
  -p '{"spec": {"selector": {"version": "green"}}}'
 
# All traffic now goes to green instantly

Step 6: Rollback if Needed

bash

# If something breaks, switch back instantly
kubectl patch service myapp \
  -p '{"spec": {"selector": {"version": "blue"}}}'
 
# Traffic is back on blue — no downtime

Step 7: Clean Up Blue When Stable

After green has been stable for a day or two:

bash

# Delete the old blue deployment to free resources
kubectl delete deployment myapp-blue
 
# Now green becomes the new "blue" for the next release
# Next time, deploy "blue" with v3.0 and switch from green → blue

Blue-Green on AWS with ALB

AWS Application Load Balancer has native blue-green support using weighted target groups.

bash

# Create two target groups: blue and green
aws elbv2 create-target-group \
  --name myapp-blue \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-xxx
 
aws elbv2 create-target-group \
  --name myapp-green \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-xxx
 
# Forward rule: 100% to blue
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --conditions '[{"Field":"path-pattern","Values":["/*"]}]' \
  --actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "arn:...:myapp-blue", "Weight": 100},
          {"TargetGroupArn": "arn:...:myapp-green", "Weight": 0}
        ]
      }
    }
  ]'

To switch to green, update weights:

bash

# Switch to green — instant
aws elbv2 modify-rule \
  --rule-arn arn:... \
  --actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "arn:...:myapp-blue", "Weight": 0},
          {"TargetGroupArn": "arn:...:myapp-green", "Weight": 100}
        ]
      }
    }
  ]'

AWS CodeDeploy also has built-in blue-green deployment support for ECS and EC2.

The Database Problem

The hardest part of blue-green deployment is database schema changes.

If v2.0 adds a new column or renames a field, and v1.0 doesn't know about it, you have a problem during the switch.

Solution: Expand-Contract pattern (3-phase migration)

Phase 1 (Expand):
  Deploy v2.0 that can handle BOTH old and new schema
  Both blue and green work with the old schema
  
Phase 2 (Migrate):
  Run database migration (add new column, keep old one)
  Both old and new code work during migration
  
Phase 3 (Contract):
  Remove backward compatibility from code
  Remove old column from database

This means your app needs to be written to tolerate both schema states during the transition. It's more work, but it's the correct way to handle it.

When NOT to Use Blue-Green

Blue-green has costs:

Double the resources — You run two full environments simultaneously. For large clusters, this is expensive.
Stateful services are tricky — Databases, caches, and services with local state complicate the swap.
Shared infrastructure — If blue and green share a database, schema changes still require coordination.

For stateless microservices with no schema changes, blue-green is nearly free and straightforward.

Blue-Green with ArgoCD

If you use ArgoCD, the Argo Rollouts extension adds blue-green support natively:

yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    blueGreen:
      activeService: myapp-active      # Points to live version
      previewService: myapp-preview    # Points to new version
      autoPromotionEnabled: false      # Manual promotion
      scaleDownDelaySeconds: 30        # Keep blue for 30s after switch
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0

bash

# After deploying, promote manually when ready
kubectl argo rollouts promote myapp
 
# Or rollback
kubectl argo rollouts abort myapp

Argo Rollouts handles the Service selector switching automatically.

Key Takeaways

Blue-green = two environments, instant traffic switch
Zero downtime releases and instant rollback
Best for stateless services; needs care with databases
Implement in Kubernetes using labels + Service selector patch
Use Argo Rollouts for automated blue-green in GitOps workflows
Costs 2x compute during the overlap window

For hands-on practice, Kubernetes Deployments Masterclass on Udemy covers deployment strategies in depth with real examples.

Once you understand blue-green, canary deployments are the natural next step — same idea, but you can send 5% of traffic to green first to validate before full switch.

What is Blue-Green Deployment? Explained Simply for Beginners (2026)

The Problem: Risky Deployments

The Blue-Green Idea

Blue-Green vs Rolling Update vs Canary

How Blue-Green Works in Kubernetes

Step 1: Deploy Blue (current production)

Step 2: Service Points to Blue

Step 3: Deploy Green (new version)

Step 4: Test Green Before Switching

Step 5: Switch Traffic to Green

Step 6: Rollback if Needed

Step 7: Clean Up Blue When Stable

Blue-Green on AWS with ALB

The Database Problem

When NOT to Use Blue-Green

Blue-Green with ArgoCD

Key Takeaways

Stay ahead of the curve

Related Articles

Jenkins vs Tekton — Which CI Tool Should You Use for Kubernetes in 2026?

What is GitOps? Explained Simply for Beginners (2026)

Argo Rollouts vs Flagger — Which Canary Deployment Tool Should You Use? (2026)

Comments