When should you NOT use Blue/Green Deployment?

Avoid blue-green when your database schema changes are not backward-compatible — both environments share state and the old app may break on a new schema. Do not use it for services where running two versions simultaneously causes correctness issues (e.g. exclusive queue consumers).

When is Blue/Green Deployment the right choice?

Use blue-green when you need instant rollback — switching traffic back is a single load-balancer change, not a re-deploy. Apply it when the cost of downtime exceeds the cost of running two identical environments simultaneously. Combine with smoke tests against the green environment before flipping traffic — the idle environment is a free staging slot.

← Back to glossary

Blue/Green Deployment

devops PHP 5.0+ Intermediate

Also Known As

blue-green deploy blue green strategy zero-downtime blue green

TL;DR

Maintaining two identical production environments and switching traffic between them for zero-downtime releases and instant rollback.

Explanation

Blue/Green deployment keeps two production-identical environments. The live environment (say, blue) serves all traffic while the new release is deployed to the idle environment (green) and tested. Traffic is switched (via load balancer or DNS) from blue to green instantaneously. If issues arise, switching back to blue provides immediate rollback. The main costs are double infrastructure and the challenge of shared state (database migrations must be backward compatible with both versions during switchover). Blue/Green is distinct from canary releases, which gradually shift a percentage of traffic.

Diagram

flowchart LR
    LB[Load Balancer] -->|100% traffic| BLUE[Blue<br/>v1.2 LIVE]
    LB -.->|0% traffic| GREEN[Green<br/>v1.3 IDLE]
    subgraph After Deploy
        LB2[Load Balancer] -->|100% traffic| GREEN2[Green<br/>v1.3 LIVE]
        LB2 -.->|0% fallback| BLUE2[Blue<br/>v1.2 STANDBY]
    end
style BLUE fill:#1f6feb,color:#fff
style GREEN fill:#238636,color:#fff

Watch Out

⚠ Blue-green does not solve database migrations — if the new code requires a column that does not exist yet, the green environment crashes on startup. Always expand-then-migrate: add the column first, deploy, then drop the old one.

Common Misconception

✗ Blue-green deployment eliminates all deployment risk. Blue-green eliminates downtime and enables instant rollback, but the new version runs against real production data — a data migration bug in the green environment affects production immediately and cannot be rolled back by switching traffic alone.

Why It Matters

Blue-green deployment gives you instant, zero-downtime rollback — if the new version has a critical bug, you flip the load balancer back to the previous environment in seconds rather than scrambling to redeploy.

Common Mistakes

Running database migrations before switching traffic — if the migration breaks, rollback is now impossible without data loss.
Not keeping both environments warm — a cold "green" environment has cache misses and slower initial responses.
Forgetting to update background workers when switching — jobs may still be routed to the old environment.
Treating blue-green as a substitute for testing — it reduces recovery time, it does not replace pre-deployment validation.

Avoid When

Avoid blue-green when your database schema changes are not backward-compatible — both environments share state and the old app may break on a new schema.
Do not use it for services where running two versions simultaneously causes correctness issues (e.g. exclusive queue consumers).

When To Use

Use blue-green when you need instant rollback — switching traffic back is a single load-balancer change, not a re-deploy.
Apply it when the cost of downtime exceeds the cost of running two identical environments simultaneously.
Combine with smoke tests against the green environment before flipping traffic — the idle environment is a free staging slot.

Code Examples

💡 NoteThe bad deploy stops the server, deploys, and restarts — causing downtime. The fix deploys to the idle green environment, runs health checks, then flips the load balancer with zero user-visible interruption.

✗ Vulnerable

// Single environment deploy — downtime during swap:
// 1. Stop app server
// 2. Deploy new code
// 3. Restart app server  <- downtime window here
// 4. Test (on live traffic)

// Blue-green: no downtime:
// 1. Deploy to green (idle environment)
// 2. Test green
// 3. Switch load balancer from blue to green — instant, zero downtime
// 4. Keep blue as instant rollback

✓ Fixed

# Blue = current live, Green = new version
# 1. Deploy new version to Green environment (zero traffic)
nginx -s reload  # after updating upstream to green

# 2. Smoke test Green
curl https://green.internal/health

# 3. Switch load balancer to Green
# nginx upstream config:
upstream app {
    # server blue-app:9000;  ← comment out
    server green-app:9000;   # ← activate
}

# 4. Monitor — rollback in seconds by reversing the upstream swap
# 5. Decommission Blue after confidence period

References

↗ https://martinfowler.com/bliki/BlueGreenDeployment.html