Rolling vs Blue-Green vs Canary Deployment: How to Choose

The three strategies in one sentence each

• Rolling - replace old instances with new ones a few at a time, on the same fleet.
• Blue-green - start a full second fleet with the new version, then switch all traffic to it at once.
• Canary - send a small share of traffic (for example 5%) to the new version, watch error rates, then increase the share step by step.

Rolling deployment

# One instance at a time: drain, replace, wait until ready, continue
for pod in 1 2 3; do
  echo "pod $pod: drain -> replace -> wait for ready"
done

• Cost: none extra. You reuse the existing capacity (at most one or two extra instances while replacing).
• Blast radius: during the rollout, users can hit old or new instances. If the new version is bad, the share of users affected grows as the rollout continues, so stop it early.
• Tooling: nothing special. This is the default strategy of a Kubernetes Deployment (strategy: RollingUpdate).
• Watch out: old and new versions run at the same time, so they must be compatible (API contracts, database schema).

Blue-green deployment

• Cost: about 2x capacity during the switch, because both fleets run.
• Blast radius: all users move at once. But rollback is instant: point the load balancer back at the old fleet.
• Tooling: a load balancer or router you can switch in one step (nginx upstream, cloud load balancer, a Kubernetes Service selector).
• Good for: releases where you want no mixed-version period and the fastest possible rollback.

Canary deployment

95% -> v1   (old)
 5% -> v2   (new)   watch errors, then 25% -> 50% -> 100%

• Cost: small. A few new instances next to the old ones.
• Blast radius: the smallest. Only the canary share sees a bad release, and only until you roll back.
• Tooling: you need weighted traffic splitting - a service mesh (Istio, Linkerd), a load balancer that supports weights, or a tool like Argo Rollouts or Flagger. You also need metrics to decide when to promote.
• Good for: high-traffic services where even a short full outage affects many users.

Side-by-side comparison

	Rolling	Blue-green	Canary
Extra infra cost	None / minimal	~2x during switch	Small
Mixed versions live	Yes	No	Yes (by design)
Rollback	Roll back again	Instant switch	Shift traffic back
Needs traffic splitting	No	No (one switch)	Yes
Needs good metrics	Helpful	Helpful	Required

How to choose: a worked example

Workload constraints:

• 3 replicas, steady traffic
• The budget does not allow a second full copy of the infrastructure
• No service mesh or weighted load balancer is available
• A bad release must reach only part of the users, for a short time

Go through the options:

1. Blue-green needs 2x capacity during the switch. The budget rules it out.
2. Canary needs weighted traffic splitting. There is none, so a "5% canary" is not possible - traffic simply goes wherever the Service sends it.
3. Rolling needs no extra capacity and no extra tooling. Replacing one of three replicas at a time limits a bad release to part of the traffic, and you can stop the rollout as soon as errors appear.

Rolling wins. This is why it is the default for most workloads.

Rules of thumb

• Start with rolling. Move away from it only when a constraint forces you.
• Choose blue-green when mixed versions are a problem or rollback must be instant, and you can pay for double capacity during the switch.
• Choose canary when traffic is high enough that testing on a small share of real users is worth the extra tooling and monitoring.
• Whatever you choose, add readiness probes so traffic only reaches instances that are ready.