Skip to main content
>_ supraj.dev
TOPIC DEVOPS
Canary Deployments rolling out changes to a small subset before full release
IN 10 SECONDS

A canary deployment routes a small percentage of traffic (e.g., 5%) to the new version while the rest hits the stable version. You monitor metrics — error rate, latency, throughput — and if everything looks good, you gradually ramp up to 100%. If something goes wrong, you route all traffic back to the old version instantly.

GOTCHA Canaries only catch issues that manifest under real traffic. They won't catch issues with edge cases, specific user cohorts, or data migrations. Always pair canaries with feature flags and integration tests.
HOW A CANARY ROLLOUT WORKS
01 New version is deployed alongside the stable version, both behind the same load balancer or service mesh.
02 Traffic split the load balancer sends 5% of requests to the canary, 95% to stable.
03 Monitoring error rate, p99 latency, and business metrics are compared between canary and baseline.
04 Auto-promotion if the canary passes the observation window (e.g., 10 min with no errors), traffic shifts to 25%, 50%, then 100%.
05 Rollback if the canary shows elevated errors, all traffic goes back to stable and the canary is terminated.
POKE IT YOURSELF
kubectl set image deployment/my-app canary=my-app:v2 — update the canary pod's image
kubectl rollout undo deployment/my-app — rollback a deployment