Canary Release
Canary Release
A technique for releasing new features to a small subset of users first to verify safety before a full rollout.
In Simple Terms
A canary release is a technique where a new program is made available to only a small group of users before rolling it out to everyone. First, just one server is switched to the new version, and the behavior of the users who access it is monitored. Once it's confirmed that no major issues arise, the update is gradually rolled out to other users over the course of several days.
Behind the Name
A combination of 'canary' and 'release.' The name comes from the old mining practice of carrying a canary in a cage underground to detect toxic gases. Just as the canary would signal danger first, a canary release is designed to catch problems in a system early, before they affect all users.
Take a Closer Look!
Canary release is a technique for deploying a new system or feature by introducing it first to only a specific group or a subset of servers, rather than making it available to everyone at once.
In simple terms, it's a way to do a limited trial launch in production in order to minimize risk. Even if the new code has a bug, catching the problem at a small scale makes it much easier to prevent the issue from spreading across the entire service.
In practice, traffic is configured so that only a small fraction of all requests — for example 5% or 10% — is routed to the new version of the server. That traffic is closely monitored for errors or performance slowdowns.
If a problem is found, traffic to the new version can be cut off immediately and the system rolled back to its previous state. If everything looks good, the share of traffic directed to the new version is gradually increased. Once all users are on the new version, the release is complete.
This approach of releasing gradually and verifying safety at each step is applied across many different deployment strategies. Beyond routing traffic at the infrastructure level, it is also common to use app store features to deliver app updates to users in stages, or to combine this with feature flags that enable new functionality only for specific users. In every case, the underlying principle is the same: reduce the risk of switching everything over all at once.