Blue/Green Deployment Fundamentals

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.
• Blue/Green switches the whole application; feature flags control individual features. Combining them provides rollback options at both the infrastructure and feature layers.

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.

flowchart TB
    LB[Load Balancer]
    LB --> Blue
    LB -.-> Green

    subgraph Blue[Blue - ACTIVE]
        B1[v1.0.0]
    end

    subgraph Green[Green - STANDBY]
        G1[v1.1.0]
    end

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

flowchart TD
    A{Downtime acceptable?}
    A -->|Yes| B[Recreate]
    A -->|No| C{Rollback speed critical?}
    C -->|Yes| D[Blue/Green]
    C -->|No| E{Need incremental validation?}
    E -->|Yes| F[Canary]
    E -->|No| G[Rolling Update]

Benefits and limits

Benefits

Zero-downtime switching

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

flowchart LR
    subgraph before[Before the switch]
        U1[Users] --> LB1[LB: 100% Blue]
        LB1 --> B1[Blue v1.0]
        G1[Green v1.1]
    end

    subgraph after[After the switch]
        U2[Users] --> LB2[LB: 100% Green]
        LB2 --> G2[Green v1.1]
        B2[Blue v1.0]
    end

    before -.->|Instant switch| after

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

Plan how to preserve existing Blue users' sessions during the switch.

flowchart LR
    subgraph problem[Session loss problem]
        U[User] -->|Before the switch| B[Blue<br/>Session: server memory]
        U -.->|After the switch| G[Green<br/>No session!]
        G --> X[Logged out]
    end

Fix: use external session storage such as Redis

Stateful connections and jobs

An instant switch needs special handling for long-lived connections and in-flight jobs, unlike stateless HTTP requests. Connections can close unexpectedly, and jobs can run across 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 jobs in one environment only. This prevents duplicate execution 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

flowchart TB
    subgraph step1[Step 1: Blue serving]
        B1[Blue v1.0]
        T1[100% traffic] --> B1
    end

    subgraph step2[Step 2: Deploy Green]
        B2[Blue v1.0]
        G2[Green v1.1<br/>deploying]
        T2[traffic] --> B2
    end

    subgraph step3[Step 3: Verify Green]
        B3[Blue v1.0]
        G3[Green v1.1<br/>Health Check<br/>Smoke Test]
        T3[traffic] --> B3
    end

    subgraph step4[Step 4: Switch traffic]
        B4[Blue v1.0]
        G4[Green v1.1]
        T4[100% traffic] --> G4
    end

    subgraph step5[Step 5: Retire or hold Blue]
        G5[Green v1.1<br/>the new Blue]
        T5[traffic] --> G5
        B5[Old Blue<br/>kept for rollback]
    end

    step1 --> step2 --> step3 --> step4 --> step5

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

flowchart TD
    A{What are you changing?}
    A -->|Infrastructure / whole app| B[Blue/Green]
    A -->|An individual feature| C[Feature Flag]

    B --> B1[Version upgrade<br/>Full refactor<br/>Platform migration]
    C --> C1[A/B testing<br/>Progressive rollout<br/>Per-user features]

Using both together

In practice, combining the two techniques works well.

flowchart TB
    subgraph prod[Production]
        subgraph bg[Blue/Green deployment]
            subgraph app[Application v2.0]
                FF[Feature Flags]
                FA[Feature A: ON 100%]
                FB[Feature B: ON 50% canary]
                FC[Feature C: OFF]
            end
        end
    end

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. Zero-downtime deployment and instant rollback require double the infrastructure cost. They also require 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.