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

1. Deploy the new version alongside the current version
2. Route a small percentage of traffic to the new version (e.g. 5%)
3. Monitor error rates, response times, and application behaviour
4. If healthy, gradually increase the traffic percentage: 5% → 25% → 50% → 100%
5. Once fully rolled out, decommission the old version
6. 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

Tools and Platforms

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