Blue-Green, Canary or Rolling: Picking a Deployment Strategy

A rolling deployment replaces old instances with new ones a few at a time, so you never run double the infrastructure but you do run two versions of your code side by side for the duration of the rollout. This is the right default for most small teams: it's supported natively by most container orchestrators and needs no extra tooling.

The catch is that a bad release still reaches a slice of real users before you notice, and rollback means running another rolling deployment backward, which takes nearly as long as the original rollout. If your rollout takes ten minutes, a bad release can be live and serving traffic for most of that window before anyone catches it.

Running two code versions side by side also means your API and database schema have to tolerate both versions at once, even briefly. A rolling deploy that pairs old application code with a database column the new code expects to exist (or vice versa) is one of the more common self-inflicted outages, and it has nothing to do with which deployment strategy you picked.

Blue-green keeps two complete environments, one live and one idle, and switches traffic from one to the other all at once. The advantage is rollback speed: switching back is a routing change, not a redeploy, so a bad release is live for minutes instead of the length of a rollout. The cost is running two full copies of your production environment, which matters more once your infrastructure bill is a real number and less when you're small enough that doubling it is a rounding error.

Blue-green also complicates any deploy that includes a database migration, since both environments need to work against the same database during the switch. Migrations have to be written to be safe for the old and new code to run against simultaneously, which is a discipline worth having regardless of deployment strategy.

Say a ten-person team runs blue-green for a checkout service that processes payments. The doubled infrastructure cost for that one service, maybe a few hundred dollars a month, is small next to the cost of a bad release staying live even briefly on a payment path. The same team might reasonably run their internal admin dashboard as a plain rolling deployment, since the cost of a slow rollback there is measured in inconvenience, not revenue.

A canary release sends a small percentage of real traffic (for example, 5 percent) to the new version, watches error rates and latency against the old version, and only proceeds to full rollout if the numbers hold. This is the strategy that actually limits blast radius: a bad release affects a small slice of users for a short window instead of everyone.

The tradeoff is operational complexity. You need traffic splitting at the load balancer or service mesh layer, automated comparison of error rates between the canary and the baseline, and a clear rule for what triggers an automatic rollback. Teams that adopt canary releases without building the automated comparison step just end up watching a dashboard manually, which defeats most of the benefit.

If a bad deploy means a visible outage for paying customers, canary is worth the setup cost even at ten engineers. If a bad deploy means an internal tool is broken for twenty minutes until someone rolls back manually, rolling deployments are enough and canary infrastructure would be solving a problem you don't have.

Teams that deploy frequently tend to need less elaborate deployment strategies, not more, because each individual change is smaller and easier to reason about. Organizations in DORA's highest-performing cluster practice on-demand deployment, often shipping several times a day, while lower-performing organizations may go weeks or months between releases¹; that cadence alone shrinks the blast radius of any single release before you've added any deployment strategy on top.

A useful test: write down your last three bad deploys and how each one was actually caught, a customer complaint, an alert, an engineer noticing something off in a dashboard. If a customer complaint was the fastest detection path more than once, that's a stronger signal that you need canary-style traffic limiting than any theoretical argument about best practice.

Use these rules of thumb when choosing:

• Choose rolling when a bad deploy is tolerable and you want to avoid running duplicate infrastructure or adding new tooling.
• Choose blue-green when fast rollback matters most and you can justify running two full copies of production.
• Choose canary when a bad deploy means a visible outage for paying customers and you can take on the added operational setup.
• Before any of the three, confirm your API and database schema changes can tolerate old and new code running at the same time.