Canary release
Releasing a new version to a small slice of users first, and widening only if it behaves.
A canary release is a way to put a new version of software into production gradually. Instead of switching every user at once, you send a small share of the traffic, say 1% or 5%, to the new version while everyone else stays on the current one. Then you watch: error rates, response times, sign-ups, whatever tells you the system is healthy.
If the numbers look as good as the old version's, you widen the slice step by step, for example to 25%, then 50%, then everyone. If something goes wrong, you send all traffic back to the old version, and only a small group of users ever saw the problem. Many teams automate the whole loop: a tool shifts traffic on a schedule and rolls back on its own if a metric crosses a threshold. On AWS, CodeDeploy and Lambda can shift traffic this way; on Kubernetes, tools like Argo Rollouts and Flagger do it.
The name comes from the canaries miners once carried underground: the bird reacted to toxic gas before the people did, giving them time to get out. Compared with a blue-green deployment, which flips all traffic from one full environment to another, a canary limits how many people a bad release can hurt. The price is more complexity: two versions run at once, so they must be compatible with the same data, and you need good monitoring to know whether the canary is fine.
Keep in mind
- A small share of real traffic goes to the new version first.
- Metrics decide whether to widen the rollout or roll back.
- A bad release only reaches a small group of users.
- Both versions run at once, so they must work with the same data.
