Canary Deployment
Route a small percentage of traffic to the new version. If nothing breaks, gradually increase.
Canary deployment caps the blast radius of any software release by routing a small percentage of traffic to the new version while the rest stays on the proven stable version. Watch the canary group’s error rates, latency, and business metrics. If healthy, bump from 5% to 25% to 50% to 100%. If degraded, route that traffic back instantly. The cost of any failure is proportional to the canary percentage, never the full user base. Named after miners’ canaries: the small sacrificial early warning system that reacts before the danger reaches the full team.
How It Works
Traffic splitting (load balancer, CDN, or feature flags) + real-time metric comparison (apples-to-apples: same window, same traffic patterns). Standard ladder: 5% for 15–30 min → 25% for 1 hr → 50% for a few hours → 100%.
Example
The lab’s projects primarily use progressive deployment (iterating over time) rather than traffic-splitting canaries, but canary informs every rollout strategy: start small, measure ruthlessly, expand only with evidence. Cloudflare Workers and Vercel both support percentage routing for SaaS feature rollouts in the jobs-apply project.