Blue/Green Deployment (1): Fundamentals and Strategy

Blue/Green keeps two identical environments and switches all traffic at once, buying zero-downtime deployment and instant rollback.

TL;DR

• Blue/Green runs two identical environments side by side and switches traffic in one move, buying zero-downtime deployment and instant rollback.
• The price is double the infrastructure cost plus managing data, session, and connection consistency at the moment of the switch.
• Whole-application switching belongs to Blue/Green and per-feature control belongs to feature flags; using both gives a rollback option at the infrastructure layer and at the feature layer.

What is Blue/Green deployment?

Blue/Green deployment is a strategy that runs two identical environments (Blue and Green) at the same time and switches traffic between them in a single move.

• Blue: the stable version currently serving production (old)
• Green: the environment where the new version is deployed and verified (new)

The traffic switch is controlled by load balancer or service routing configuration. Any problem allows an immediate rollback to Blue, which makes it one of the core techniques for zero-downtime operation.

Why "Blue" and "Green"?

The colors carry no special meaning. They are simply a naming convention for telling the two environments apart. Some organizations use terms such as "A/B", "Primary/Secondary", or "Live/Staging" instead.

Comparing deployment strategies

Understanding Blue/Green is easier alongside the other major deployment strategies.

Characteristics by strategy

Resource and complexity comparison

• Recreate: no extra resources, has downtime, low operational complexity, no test isolation
• Rolling Update: minimal extra resources, no downtime, low operational complexity, partial test isolation
• Blue/Green: double the resources, no downtime, medium operational complexity, complete test isolation
• Canary: minimal to medium extra resources, no downtime, high operational complexity, partial test isolation
• A/B Testing: medium extra resources, no downtime, high operational complexity, partial test isolation

Which strategy to pick when

Benefits and limits

Benefits

Zero-downtime switching

A load balancer switch alone deploys the new version without interrupting service.

Complete isolation

The Green environment allows final testing under conditions identical to production.

• Run internal tests before any real traffic arrives
• Performance testing, security scanning, and QA validation are all possible
• Problems found there never reach users

Extremely fast rollback

When a problem shows up, only the routing configuration changes.

# Rollback duration (estimates that vary by environment and scale)
Recreate:       5-10 min (redeployment)
Rolling Update: 2-5 min  (incremental rollback)
Blue/Green:     seconds  (routing change only)

Limits

Infrastructure cost

Two identical environments are required, which is a substantial expense.

• Standard deployment: 10 servers x $100/month = $1,000/month
• Blue/Green: 20 servers x $100/month = $2,000/month (+$1,000/month)

Cost optimization: part 4 of this series covers spot instances, autoscaling, and other ways to cut the bill.

Data consistency

The DB state and cache data must be in sync at the moment of the switch.

Problem scenario:

1. A user creates an order on Blue (v1)
2. The order data is written to the DB
3. Traffic switches to Green (v2)
4. Green may hit a schema mismatch when processing that order

Session persistence

Existing Blue users need a plan for surviving the switch without losing their sessions.

Fix: use external session storage such as Redis

Stateful connections and jobs

Unlike stateless HTTP requests, long-lived connections and in-flight jobs are the blind spot of an instant switch. They can be cut mid-flight or straddle two versions.

• Long-lived connections (WebSocket, streaming): keep Blue alive after the switch until existing connections finish (connection draining), then tear it down.
• Asynchronous jobs (queue consumers): the queue message format must stay compatible across versions so Green can process messages Blue enqueued.
• Batch and cron jobs: use a distributed lock, or run them in one environment only, so the two environments do not execute the same job twice during the switch.

All three connect directly to connection draining and session externalization in part 4.

The basic deployment flow

A five-step deployment process

Checklist for each step

Comparison with feature flags

Blue/Green deployment and feature flags both serve "safe release", but they apply at different layers and for different purposes.

Conceptual comparison

A feature flag example

# Feature flag usage example
def get_checkout_page(user):
    if feature_flags.is_enabled("new_checkout", user):
        return render_new_checkout()  # new feature
    else:
        return render_old_checkout()  # existing feature

The first argument to is_enabled is the flag key and the second is the target user. The same code branches between the new and the existing feature per user.

Which one to use when

Using both together

In practice, combining the two techniques works well.

Advantages of the combination:

• Blue/Green gives safe deployment at the infrastructure level
• Feature flags give fine-grained control at the feature level
• When something breaks, there are two independent rollback options

Summary

Blue/Green keeps two identical environments and switches all traffic at once by changing load balancer routing. The price of zero-downtime deployment and instant rollback is double the infrastructure cost and the burden of managing data, session, and connection consistency at the switch. Whole-application switching fits Blue/Green while per-feature control fits feature flags. Using both provides a rollback option at the infrastructure layer as well as the feature layer. The next post covers the operational problems that appear at the moment of the switch: data consistency, session persistence, and connection draining.