What is blue-green deployment in simple terms?

Blue-green deployment runs two identical production environments -- blue (live) and green (new version). You deploy your new release to green, test it, then switch all traffic from blue to green. If something goes wrong, you switch back. Downtime is near-zero because the switch is instant.

What is the difference between blue-green and rolling deployment?

A rolling deployment gradually replaces old instances with new ones -- a few at a time -- so both versions run simultaneously during the rollout. Blue-green keeps both environments fully separate and switches all traffic at once. Blue-green is faster to roll back but requires double the infrastructure. Rolling deployments are resource-efficient but slower to fully roll back.

What is a canary deployment?

A canary deployment routes a small percentage of traffic -- say 5% -- to the new version while 95% continues to use the old. This lets you validate the new version against real production traffic before a full rollout. Canary sits between rolling and blue-green: more risk control than rolling, less infrastructure than blue-green.

How do you handle database migrations in blue-green deployments?

Database migrations are the hardest part of blue-green. Both blue and green environments share the same database during the transition, so migrations must be backward-compatible -- you cannot drop a column while blue is still reading it. The standard approach is expand-contract: first add the new column (both versions compatible), deploy green, then remove the old column in a subsequent migration after blue is retired.

What is Blue-Green Deployment?

Blue-green deployment is a release strategy that eliminates downtime by running two identical production environments simultaneously. One environment -- call it blue -- serves live traffic. You deploy your new version to the other -- green -- test it thoroughly, then switch the load balancer to route all traffic to green. Blue remains idle as an instant rollback target. If the new version has a critical bug, switching back takes seconds.

The pattern was described by Martin Fowler and has become a standard technique for teams that need zero-downtime releases. It sits alongside rolling deployments and canary releases as one of three main traffic-shifting strategies in modern deployment practice. All three rely on the containerisation and orchestration that Docker and Kubernetes provide.

How the Switch Works

The core mechanism is simple: a load balancer (or DNS, or a Kubernetes Service selector) points to either the blue or green environment. Switching is atomic from the outside -- users do not see a transition state, they see one version or the other.

Here is a blue-green deployment implemented in Kubernetes using two Deployments and a Service that switches between them by changing its selector:

# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
  labels:
    app: myapp
    slot: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      slot: blue
  template:
    metadata:
      labels:
        app: myapp
        slot: blue
    spec:
      containers:
        - name: myapp
          image: myapp:1.4.2
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
  labels:
    app: myapp
    slot: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      slot: green
  template:
    metadata:
      labels:
        app: myapp
        slot: green
    spec:
      containers:
        - name: myapp
          image: myapp:1.5.0   # new version
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10

---
# service.yaml -- switch traffic by changing 'slot: blue' to 'slot: green'
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    slot: blue     # change to 'green' to switch traffic
  ports:
    - port: 80
      targetPort: 3000

The traffic switch is a single kubectl patch command:

kubectl patch service myapp -p '{"spec":{"selector":{"slot":"green"}}}'

To roll back:

kubectl patch service myapp -p '{"spec":{"selector":{"slot":"blue"}}}'

The readiness probe ensures green pods only receive traffic once they are healthy. Blue pods remain running and can take traffic back instantly.

The Database Migration Problem

Infrastructure switching is the easy part. Databases are the hard part of blue-green deployments.

During the cutover window, both blue and green may need to read and write to the same database. If your new version requires a schema change -- adding a NOT NULL column, renaming a column, changing a data type -- you cannot simply run the migration before switching, because blue is still running with the old schema expectations.

The correct technique is the expand-contract pattern (also called parallel change):

Expand: run a migration that is backward-compatible with both versions -- add the new column as nullable alongside the old one. Both blue and green can now function.
Deploy green: switch traffic to the new version, which writes to both columns.
Contract: after blue is retired and green is stable, run a cleanup migration to remove the old column and enforce the new constraint.

This requires two separate deployment cycles for every breaking schema change, but it is the only safe approach for zero-downtime releases with a shared database.

Blue-Green vs Rolling vs Canary

Blue-green gives the cleanest instant rollback but requires double the infrastructure capacity and cannot partially validate with real traffic before a full switch.

Rolling replaces instances incrementally -- resource-efficient, but rollback means running another rolling update in reverse, which takes time proportional to your fleet size.

Canary sends a fraction of real traffic to the new version first -- ideal for validating behaviour under production conditions before a full rollout. The cost is added complexity in the traffic routing layer.

For most teams, canary deployments via feature flags or weighted routing are the most practical combination of safety and resource efficiency. Blue-green is the right choice when an instant clean rollback is the non-negotiable requirement.

Deployment strategies are core DevOps tools knowledge that CloudPros covers in the Kubernetes and CI/CD modules.

How the Switch Works

The Database Migration Problem

Blue-Green vs Rolling vs Canary

Frequently Asked Questions