Blue-Green vs Canary vs Rolling Deployments: Choosing Based on Blast Radius

Sooner or later a bug gets past your tests and into production. You can't fully prevent that, but you can decide how many users it reaches before you stop it.

Rolling, blue-green and canary deployments are three ways to make that decision. Rolling changes which servers run the new code, blue-green changes which environment users are sent to, and canary changes how many users see the new version.

Quick Answer

Pick a deployment strategy by asking how many users a bad release can reach before you notice it and stop it. A rolling deployment replaces your servers a few at a time and costs the least, but the old and new versions run side by side while it happens. A blue-green deployment keeps two full copies of production and moves all traffic from one to the other, so switching back is fast, but everyone gets the new version at once. A canary deployment sends a small share of real traffic to the new version first, which keeps early damage smallest, as long as you can control that share precisely and spot problems quickly.

What Is Blast Radius?

Blast radius is how far the damage from a bad release spreads before someone stops it. It depends on two things: how many users see the new version, and how long it takes you to notice the problem and act.

The AWS blue/green deployments whitepaper puts it the same way: impact is "limited to the window of time between green environment issue detection and shift of traffic back to the blue environment." Exposing only a few users doesn't help much without monitoring, because the bug keeps running until a customer complains.

The Problem: Old and New Versions Share Everything

New code uses the same database, cache and queues as the version it replaces, and for a while both versions run at once. That causes three kinds of trouble.

• If the new version deletes a database column the old version still reads, the old servers start failing.
• If you move all traffic in one step, a bug reaches every user at once.
• Rolling back the code doesn't undo a database change, a sent email or a charged card.

The Solution: Pick the Strategy by How Much Damage You Can Accept

Each strategy moves something gradually, and that is where both its strengths and its costs come from.

Rolling: Replace Servers a Few at a Time

A rolling deployment swaps your servers for the new version in small batches, so the service stays up the whole time. Kubernetes does this by default, and a readiness check, a small test each new copy has to pass, keeps traffic away from copies that aren't ready yet.

The catch is that V1 and V2 run side by side for the whole rollout, so both have to work with the same database and services. A bug that still returns normal-looking responses also passes the readiness check and spreads to every server.

Blue-Green: Switch Between Two Environments

You run the new version in a separate environment called Green, test it, then move every user to it in one step. If it misbehaves, you send them back to Blue. That only works instantly while Blue is still running, and Argo Rollouts, a popular Kubernetes add-on, shuts the old version down 30 seconds after the switch by default.

The switch itself can lag. If you switch by changing DNS, some clients keep using the old address for a while, as AWS warns. And since Blue and Green usually share one database, a change that breaks V1 leaves Blue useless even though its servers are still up.

Canary: Let a Small Group Try It First

A canary sends a small share of real users to the new version and widens it only while things look healthy. Google Cloud describes it as a gradual rollout that reaches a limited group before everyone else. The percentages above are an example, so pick stages that suit your traffic and how risky the change is.

At each stage, watch error rates, response times and business results. A payments API can return success on every request while fewer payments actually go through. Tools like Argo Rollouts can check these numbers for you and send everyone back to the old version when they get worse.

Rolling vs Canary: Servers vs Users

Rolling and canary both run old and new versions at the same time, so they look alike. Rolling is about swapping servers safely. Canary is about how many users reach the new version while you watch it.

Kubernetes on its own splits traffic only roughly, by the number of copies. The Kubernetes canary tutorial runs three old copies and one new one and gets about 25% of traffic to the new one. Argo has the same limit without a traffic router: ask for 5% with ten copies and you get one new copy, which is 10%. For exact percentages, you need a service mesh, ingress controller or load balancer that supports weighted routing.

How to Choose

• Rolling suits routine releases that work alongside the old version, when cost and simplicity matter.
• Blue-green suits releases where a clean switch and a fast way back matter most, and you can pay for a second environment.
• Canary suits risky changes you want a small group to try first.
• Blue-green plus canary gives you a separate environment to test in, then a gradual move of users. AWS notes that weighted DNS records make this easy.

Trade-offs

None of these strategies removes risk. Each one moves it somewhere else.

The database doesn't roll back. Use the expand-and-contract approach: add the new structure next to the old one, ship code that works with both, copy the data across, switch over, and remove the old structure only once no old version is running. AWS recommends the same order for schema changes.

Background work outlives the switch. Queued jobs, caches and sessions created by one version may be picked up by the other, so keep their formats readable by both until the move is finished.

Monitoring decides everything. Decide what "failing" looks like before you deploy, and practise switching back before you need to. A small canary is no help if you can't tell it is failing.

Each strategy has a case where it's the wrong choice. Rolling breaks down when two versions can't run together. Blue-green breaks down when you can't afford a second environment, or the two can't safely share data. Canary breaks down when your traffic is too low to show a clear pattern, or you have no numbers that would reveal a problem.

Conclusion

On Monday, take your riskiest upcoming release and answer three questions: who sees it first, how you would know within minutes that it was failing, and whether the old version still works with the database after it ships. If the first answer is "everyone", move to a canary or a gradual blue-green switch. If the second is "a customer would tell us", fix your monitoring first. If the third is "no", split the database change with expand-and-contract before anything else.