Blue/Green vs Canary Deployments: Which to Use When

Quickstart

Use this as a fast decision + rollout checklist when you’re about to deploy.

Overview

This post explains blue/green vs canary deployments with mental models, trade-offs, and practical implementation steps. You’ll learn how traffic shifting works, what to watch during rollout, and which strategy fits common real-world constraints (databases, caching, and compliance).

Neither strategy is “better.” The right choice depends on what you can afford: duplicate capacity, slower rollouts, operational complexity, and the cost of failure. The goal is the same: reduce risk without slowing delivery to a crawl.

Core concepts

To choose between blue/green and canary deployments, you need three mental models: traffic shifting, state compatibility, and rollout signals.

1) Traffic shifting: where the “switch” actually lives

“Switching traffic” can happen in different places: a load balancer, Kubernetes Service selector, Ingress controller, service mesh (weighted routing), or DNS. Your platform determines how fast and how safely you can move traffic.

2) State compatibility: the database is usually the real constraint

Most rollback pain isn’t in app code—it’s in schemas, migrations, caches, and messages. If new code writes data the old code can’t read, “rollback” becomes “incident.”

3) Rollout signals: what you watch to decide “continue or abort”

A rollout strategy is only as good as the signals you use to judge it. Pick a small set of metrics that reflect user impact, then set thresholds before you start.

Step-by-step

This section shows practical ways to implement blue/green and canary deployments, with examples you can adapt to Kubernetes (or similar platforms). The steps are intentionally “platform-agnostic” first, then the code examples show concrete mechanics.

Step 1 — Decide what “rollback” means for your system

Step 2 — Implement blue/green (two versions, one clean switch)

Blue/green works best when you can run two full versions at once and your traffic switch is reliable and fast. The classic pattern: keep blue serving users while you deploy green, validate green, then flip.

Example: two Deployments (blue + green) and a Service selector you can switch.

<!-- Example 1: Kubernetes blue/green with a Service selector switch -->
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
      track: blue
  template:
    metadata:
      labels:
        app: myapp
        track: blue
    spec:
      containers:
        - name: app
          image: ghcr.io/acme/myapp:1.8.4
          ports:
            - containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
      track: green
  template:
    metadata:
      labels:
        app: myapp
        track: green
    spec:
      containers:
        - name: app
          image: ghcr.io/acme/myapp:1.9.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
    track: blue  # switch to "green" during cutover
  ports:
    - port: 80
      targetPort: 8080

Step 3 — Implement canary (small slice first, then ramp)

Canary deployments focus on blast-radius control. You route a small percentage of traffic to the new version, watch your signals, then increase gradually. This is ideal when you can’t afford a full parallel environment or when risk is uncertain.

Example: Argo Rollouts-style canary steps (weights + pauses) to automate gradual rollout.

<!-- Example 2: Canary rollout with weighted steps (Argo Rollouts style) -->
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 6
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: app
          image: ghcr.io/acme/myapp:1.9.0
          ports:
            - containerPort: 8080
  strategy:
    canary:
      stableService: myapp-stable
      canaryService: myapp-canary
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }

Step 4 — Automate the “flip” and the “abort”

The best rollout strategy is the one you can execute consistently under pressure. Even if you have a fancy controller, keep a plain, auditable way to switch traffic and roll back.

Example: a tiny bash helper to flip the Service selector (blue ↔ green) and keep it repeatable.

#!/usr/bin/env bash
# Example 3: Flip Kubernetes Service selector for blue/green cutover
set -euo pipefail

NAMESPACE="${NAMESPACE:-default}"
SERVICE="${SERVICE:-myapp-svc}"
TRACK="${1:-green}" # pass "blue" to roll back quickly

if [[ "$TRACK" != "blue" && "$TRACK" != "green" ]]; then
  echo "Usage: $0 {blue|green}"
  exit 1
fi

kubectl -n "$NAMESPACE" patch service "$SERVICE" \
  --type='merge' \
  -p "{\"spec\":{\"selector\":{\"app\":\"myapp\",\"track\":\"$TRACK\"}}}"

echo "Switched $SERVICE selector to track=$TRACK in namespace=$NAMESPACE"

Step 5 — Handle databases safely (works for both strategies)

Treat DB changes as their own rollout with its own phases. The “expand/contract” approach keeps old and new versions compatible.

Common mistakes

Most rollout failures aren’t “bad strategies.” They’re missing prerequisites: unclear success metrics, unsafe DB changes, or routing that doesn’t do what you think it does. Here are the pitfalls that show up repeatedly—plus the fixes.

FAQ

Is blue/green safer than canary deployments?

Not automatically. Blue/green is safer when you need fast rollback and your cutover is predictable. Canary is safer when you need blast-radius control and want to validate changes gradually.

When should I choose canary deployments?

Choose canary when risk is uncertain (perf changes, new dependency), when you can’t run two full environments, or when you can reliably measure health and compare new vs stable during the rollout.

When should I choose blue/green deployments?

Choose blue/green when you need a clean cutover, immediate rollback, or you operate within tight release windows. It’s also great for smaller services where running parallel capacity is affordable.

How do blue/green and canary deployments affect databases?

Both strategies require backward-compatible schema changes if old and new versions might run at the same time (which is common during rollout and rollback). Use expand/contract migrations and avoid destructive changes in the same release.

Can I combine blue/green and canary deployments?

Yes—and it’s often the best approach for high-stakes systems: run a small canary first to validate, then do a blue/green cutover once you’re confident. This gives you early signal plus a clean final switch.

What metrics should I watch during a canary rollout?

Start with 5xx rate, latency (p95/p99), and saturation (CPU/memory/DB connections), then add one business KPI if you have it. Most importantly: compare metrics per version, not only globally.

Cheatsheet

A scan-fast checklist to choose, execute, and validate a rollout strategy.

Wrap-up

Blue/green and canary deployments are both reliable ways to reduce release risk—as long as you pair them with the basics: clear signals, safe data changes, and a rollback path you can execute quickly.

If you want a simple default: use canary for uncertain risk and learning, use blue/green for clean cutovers and fast rollback. For many teams, a hybrid approach (small canary → blue/green cutover) is the sweet spot.

Related posts

• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story
• CI/CD That Stays Green: Pipeline Patterns That Scale
• GitOps Explained: Deployments You Can Roll Back With Confidence
• Terraform Mistakes: State, Modules, and the ‘One Big Plan’ Trap
• Observability 101: Logs vs Metrics vs Traces (And When You Need Each)