A canary deployment is when new software features are made available to a small subset of users ahead of a larger release. Whether the users selected for canary deployments are completely random or highly targeted, the goal is typically to improve the quality, viability, and chance of success of a feature ahead of a bigger rollout.

If you’re wondering why it’s called a “canary deployment,” that’s a good question. Back in the day, miners would put canaries into coal mines as a way to measure the amount of toxic gases that were present. As you can imagine, things didn’t always work out in the best way for the canaries. 

When it comes to software development and new releases, a canary deployment substitutes a bird for software users (although hopefully in a much safer way), wherein the pre-selected group of users helps you identify bugs, breaks, and hazards of a new feature. With the information collected from your user group, you can then strengthen your feature so it’s ready for a wider audience.  

Benefits of a canary release 

For some added perspective, decades ago, when new software was released on a quarterly, annual, or even bi-annual basis, companies would rigorously develop and test internally and then basically cross their fingers and hold their breath when releasing it to the public. 

Think of a new videogame that was slated for release to home consoles in the 1980s or 1990s. The consoles that ran the games weren’t connected to the internet, which meant software updates weren’t possible. The game’s entire software—all it was and all it would ever be—was contained in a single cartridge or disc. Any issues or glitches that came along with the game were permanent.   

With this sort of release, often dubbed a “big-bang deployment,” all updates were shipped at once and virtually everything was on the line for the companies responsible during these events. Given the stakes of the drawn-out release schedule, the impact of a poor-performing or glitch-filled release could range from the annoying to the catastrophic depending on the severity. 

Today, in the age of continuous deployment—when companies are now pushing out new software features and updates multiple times every day—it’s generally easier to fix a bug, whether it’s in a videogame, mobile app, or enterprise solution. 

However, the sheer volume of releases today also increases the chance that something could go wrong. Luckily, though, there are also a lot more ways to mitigate the risks to your organization, products, and end users, and that’s where canary deployments come in. 

Canary deployments give you more control and confidence over releases 

Among the biggest benefits of a canary deployment is more control over your releases. You’ll feel more confident knowing that if something does go wrong with your release, its impact will only be felt temporarily by an extremely small group of users within the canary version. This makes features that could be considered risky, for whatever reason, good candidates for a canary testing and deployment. 

And while the goal always remains releasing the highest-quality software feature possible, one of the best ways to ensure you achieve that goal is by getting it in front of actual users, which a canary deployment facilitates. 

In that way, canary deployments can also strengthen your releases in terms of engagement. If you roll out a new feature, and the data says your group of users in the canary version are immediately loving it, there’s a good chance your broader audience will too. Of course, the opposite can also be true, but that just gives you more opportunities to rollback, refine, and iterate on the feature…maybe through more canary deployments?

If we want to step back from the perspective of a developer for a moment, canary deployments can also help build demand for a new feature. For instance, if you roll out an extremely cool new feature to a select group of influencers and get them talking about it publicly, it can kickstart demand and appetite for a larger release. 

That brings us to why canary releases are also good for a company’s bottomline. Since these series of microtests are on real users, not only will you build more successful features in this age of continuous delivery, but you’ll also dramatically reduce the cost and impact of a system failure.

Visual Example: Canary deployment followed by a progressive rollout based on geography

Blue-green deployments and what a canary release is not 


If you’re thinking canary deployments sound a lot like other types of deployments, that’s understandable. Since canary deployments are a fail-safe method, they’re easily mixed up with blue-green deployments, but let’s talk about the differences. 

A blue-green deployment is a release strategy for safely updating apps in production with zero downtime. This deployment process involves creating two identical instances of a production app behind a load balancer. At any given time, one app is responding to user traffic, while the other app receives constant updates from your team's continuous integration (CI) server.

With blue-green deployments, all traffic from your user base gets pushed into one production environment (blue) as a new version of the environment (green) is deployed. The green environment will then undergo extensive testing. Once things look good in terms of usability, speed, and overall performance, users are pushed to the new, green environment. The blue environment then acts as a standby software version in case something fails in the green. And, in that case, traffic can get routed back to the blue, stable version, hopefully with zero downtime in between. 

So with blue-green deployments, you’re basically routing users to the new production environment in a single shot, whereas canary deployments are much more targeted and gradual. 

Since we’re talking about blue-green deployments, we’ve also heard folks refer to the same engineering practice as a red-black deployment. Fear not, these two things are essentially the same engineering practice, just switching out the names of the colors.

There can also be some confusion around how blue-green deployments differ from A/B deployments. At face value, it sounds like the same sort of thing, but A/B testing can relate to just about anything, like monitoring the performance of competing email subject lines in a Marketing campaign. Blue-green deployments (and red-black deployments, for that matter) relate specifically to the engineering practice we’ve explained above, but that of course won’t stop some folks from using the two terms interchangeably.   

Can you do Kubernetes canary deployments?

In short, yes and you have options, some better than others. For example, you could use service meshes for this particular task for Kubernetes, but an easier route would be using a feature management platform. Feature management is a new category of software development tools and practices that revolves around the usage of feature flags, also sometimes referred to as feature toggles

Feature flags give you stronger controls over deployments and, in many instances, remove the need to change config files, perform blue-green deployments, and execute rollbacks. With feature management, development teams can safely run canary deployments to Kubernetes without needing to spin up multiple production instances of their application.

For a canary deployment with Kubernetes, you would wrap new functionality in a feature flag and then deploy that new version of the application to a single production environment. The chosen flag would then allow the users specifically designated to your canary group to access the new functionality. 

In the case of a canary test failure, you can simply toggle the feature flag to the “off’ position—similar to a kill switch—thereby avoiding rollbacks or redeploys completely. Conversely, if the canary test is a success, you can roll out the new app to the rest of your users as part of a larger deployment.

An effective deployment strategy 

Software releases have come a long way in the past couple decades. Likewise, with the advent of new technologies and a strong culture around knowledge sharing, development teams have so many more tools than ever before to augment their deployment process.

Canary deployments are effective strategies because they help you answer important questions and give you the flexibility to rollback features on a whim. Here’s how LaunchDarkly’s co-founder, Edith Harbaugh, describes the value of canary launches:

“Canary launches allow you to quickly identify issues that might impact your entire user base, rollback easily to a known good version, and fix the issues in a controlled environment. The net result is a better product for all.”

We’d be remiss if we didn’t again mention a way to make canary deployments a lot easier: feature flags, which let you perform canary releases in a single production environment. This greatly simplifies canary testing, especially if you’re using a feature management platform like LaunchDarkly, which allows you to use feature flags on a large scale with a high degree of sophistication.

Whatever path you choose, the goal is always to get the best possible software out to your users as fast as possible.

If you’re interested in learning more about how LaunchDarkly can support your canary deployments, sign up for a demo