3 min read
#deployments#devops#best-practices
Canary Deployment
A canary deployment is a strategy for releasing new versions with reduced risk. Instead of releasing to all users at once, you expose the new version to a small percentage of traffic first. If it behaves well, you gradually increase the percentage until it handles all traffic. If it breaks, you roll back with minimal impact.
The name comes from the old coal mining practice of using canaries to detect toxic gases. If the canary survives, it is safe to continue.
How It Works
- Deploy the new version alongside the current version
- Route a small percentage of traffic to the new version (e.g. 5%)
- Monitor error rates, response times, and application behaviour
- If healthy, gradually increase the traffic percentage: 5% → 25% → 50% → 100%
- Once fully rolled out, decommission the old version
- If issues are detected at any stage, roll back to 0% traffic on the new version
Benefits
- Reduced blast radius — bugs only affect a fraction of users, not everyone
- Real-world validation — tests under genuine production load and data
- Gradual confidence — you observe behaviour before committing fully
- Fast rollback — you have not decommissioned the old version yet
Challenges
- Complexity — requires infrastructure that can route a percentage of traffic to specific versions
- Database compatibility — both versions run simultaneously, so schema changes must be backwards-compatible
- Monitoring — you need good observability to detect issues in the canary version
Canary vs Blue/Green
| Canary | Blue/Green | |
|---|---|---|
| Traffic split | Gradual | Instant switch |
| Old version | Stays live during rollout | On standby, taken down after |
| Risk profile | Very low — incremental | Low — instant rollback available |
| Infrastructure cost | Medium | Higher (two full environments) |
Tools and Platforms
| Platform | Canary Support |
|---|---|
| Kubernetes | Progressive delivery via Argo Rollouts or Flagger |
| AWS CodeDeploy | Linear and canary deployment configurations |
| AWS App Mesh | Traffic-weighted routing |
| Nginx / Envoy | Manual traffic weight configuration |
| Cloudflare | Traffic split via Workers |
When to Use It
Canary deployments are a good choice when:
- Your deployment risk is high (major features, significant refactors)
- You have good monitoring and alerting in place
- Your infrastructure supports traffic-weighted routing
- You want production validation with limited exposure