Engineering Practice

Blue-Green Deployments and Canary Releases: Shipping Without Downtime

Replacing a running service with a new version without ever taking it offline, and without betting the whole userbase on untested code, comes down to controlling exactly how much traffic the new version sees and how fast you can pull it back.

Published July 6, 2026

The oldest and simplest deployment approach — stop the old process, start the new one — guarantees a window where the service is down. Every strategy discussed here exists to avoid that window while still giving you a fast, reliable way to undo a bad release.

Blue-green: two full environments, one traffic switch

Blue-green keeps two complete, identical production environments running: one, say blue, serving all live traffic, and one, green, idle or running the new version. Deploying means standing up the new version on green, running whatever checks confirm it's healthy, and then flipping a router or load balancer so all traffic now points at green instead of blue.

router: active = blue
1. deploy new version to green (no live traffic yet)
2. run health checks against green
3. router: active = green   <- traffic switches instantly
4. keep blue running, idle, as an instant rollback target

Rollback is just flipping the router back to blue, which is still running the previous, known-good version and hasn't been touched. That's the entire appeal: rollback is as fast as the forward switch, because nothing about the old environment was ever modified or torn down until you're confident the new one is solid. The cost is running two full copies of the production environment simultaneously, which for anything beyond a small service means real, if temporary, doubled infrastructure spend during the deploy window.

The database migration problem blue-green doesn't solve on its own

Blue-green's clean instant-switch story assumes both environments can safely talk to the same data, which breaks down the moment a deploy needs a schema change. If green's new code expects a column that doesn't exist yet, you can't safely route any traffic to it until the migration has run — and if that migration isn't backward compatible, blue can't keep working against the changed schema either, which quietly defeats the instant-rollback story that made blue-green attractive in the first place. The standard fix is expand-contract migrations: add the new column or table in a way both old and new code tolerate, deploy the new code, let it run, and only remove anything the old code depended on in a later, separate deploy once you're sure you won't need to roll back to it.

Canary releases: control the blast radius instead of switching all at once

A canary release takes the opposite approach to risk: instead of an instant all-or-nothing switch, it sends a small percentage of live traffic — 1%, then 5%, then 25%, climbing gradually — to the new version while the rest keeps hitting the stable one. Error rates, latency, and business metrics on that small slice get watched closely before increasing the percentage further.

canary rollout:
  step 1: 1% of traffic  -> v2, watch error rate for 10 min
  step 2: 10% of traffic -> v2, watch again
  step 3: 50% of traffic -> v2
  step 4: 100% of traffic -> v2 (rollout complete)
  at any step: error spike -> route 100% back to v1

The advantage over blue-green is real-world validation with actual production traffic and real user behavior, at a scale small enough that a bug only affects a fraction of users rather than everyone at once. The cost is that a canary rollout is slower by design and needs solid, fast metrics and automated rollback triggers to be genuinely safer rather than just a delayed version of the same all-at-once risk — a canary nobody's actually watching provides none of the protection the pattern is meant to give.

Rolling deployments: the middle ground most orchestrators default to

A rolling deployment replaces instances of the old version with the new one gradually, a few at a time, until all are updated — no second full environment needed like blue-green, and no fine-grained traffic percentage control like canary, just a steady instance-by-instance replacement. It's the default in most container orchestration platforms because it needs the least additional infrastructure, but rollback means rolling the same process in reverse, which is slower than blue-green's instant router flip and gives you less controlled exposure than a canary's gradual traffic ramp.