A canary deployment routes a small fraction of production traffic to the new version, watches key metrics, and either promotes or rolls back automatically.
A canary deployment is a release strategy where the new version of a service receives a small share of production traffic (often 1-5%), while the majority stays on the current version. If key health metrics on the canary stay within tolerance, the share expands progressively (5% → 25% → 50% → 100%); if they degrade, traffic auto-shifts back and the release is halted. The pattern turns 'we broke prod' from a company-wide incident into a paged-page investigation on 1% of users.
Rolling deployment — replace instances one at a time. Simple, no traffic split, but a bad release still hits 100% of users as the rollout completes. Blue-green — run two full environments; switch traffic entirely from blue to green in one step. Fast rollback (switch back), but the switch itself exposes 100% at once. Canary — progressive traffic percentage split between old and new. Slower, safer, and the only pattern that lets automated analysis compare old vs. new on real production traffic before committing. Most modern platforms (Kubernetes + Argo Rollouts / Flagger, AWS App Runner, Cloud Run) support all three; canary is the right default for anything customer-facing.
Automated canary analysis compares canary vs. baseline on: (1) error rate — HTTP 5xx, application exceptions, dependency errors. (2) Latency — p50 and p95/p99. (3) Business signal — successful checkouts, messages sent, whatever your primary product metric is. Define thresholds: 'canary error rate must not exceed baseline by more than 20% over a 5-minute window'. Tools compute significance (Kayenta, Argo Rollouts AnalysisTemplate, Flagger MetricTemplate) and either promote or abort. Manual approval gate optional between stages for high-risk services.
Layer-7 splitting (Envoy, Istio, Linkerd, AWS ALB weighted target groups, Cloudflare Workers) routes by percentage — the default. For stateful sessions, use sticky routing so a user stays on one version through their session (prevents mixing responses from different versions). For services where user identity matters more than percentage, split by user hash — a stable slice of users tries the canary rather than random per-request. Skip canaries for pure background jobs (no live traffic to split); use shadowing (send jobs to both, discard canary output) instead.
Always have a big red button (dashboard action) to abort a canary at 0% traffic in under 30 seconds. Auto-abort at signal degradation is necessary but not sufficient — on-call engineers should be able to pull the plug on judgment alone. Canary-only alerts (page when canary is unhealthy while baseline is healthy) go to the deploy driver, not general on-call, to avoid alert fatigue. Never canary irreversible changes (destructive migrations, one-way data transformations) — canaries only save you when a rollback is possible.
Start on your most trafficked, most stateless service (usually the web tier or a specific API). Wire canary into CI/CD with one metric (error rate) and a single manual promotion gate. Once stable, add latency + business metric, automate promotion. Expand to other services one at a time. Do NOT attempt to canary every service before proving the platform on one. Expect to invest 2-4 engineer-weeks to reach 'boring, works every time' on the first service; each additional service is days once the platform is in place.
Investor directory · Fundraising library · Articles A–Z · Company funding database