Deployment Strategies: Rolling Deployment, Blue Green, Canary and Shadow Deployment

What are deployment strategies?

A deployment strategy is the plan for how a new version of your software replaces the old one in production. It decides three things: whether users see downtime, how many of them meet a bad release before you notice, and how fast you can get back to the version that worked. Everything else about a strategy follows from those three.

There are five that matter in practice, and they trade the same two resources against each other: infrastructure you have to run in parallel, and the time you spend exposed to a version you are not yet sure about. Recreate spends nothing and accepts downtime. Blue green spends double the servers and buys an instant switch. Rolling spends a little headroom and accepts a mixed fleet. Canary spends routing complexity and buys a small blast radius. Shadow spends real money to learn without risking anyone.

The five deployment strategies compared

Read that table as a ladder of cost. Most teams do not need to climb it all the way. A single application server running a business tool for 200 internal users is well served by rolling or blue green, and adding canary routing to it buys sophistication nobody will benefit from.

Recreate, or big bang deployment

Stop the old version, put the new files in place, start the new version. It is the strategy every deployment starts as before somebody complains about the gap, and it is still the correct choice in two cases: an internal tool with a maintenance window, and a change so structurally invasive that running two versions at once would corrupt data.

The honest cost is the gap, and the gap is usually longer than people estimate because it includes application boot, not just file copying. A framework that takes eight seconds to warm caches and open connections turns a one second file swap into a nine second outage. If that is unacceptable, the next rung of the ladder is cheap.

Rolling deployment

A rolling deployment replaces instances a few at a time. Take one out of the load balancer, update it, wait for it to pass a health check, put it back, move to the next. Traffic never stops because there is always a healthy pool serving it, and you only need enough spare capacity to be one instance down.

The trade is that for the duration of the roll, two versions of your application are live at once and users are hitting both. Anything that cannot tolerate that, a changed session format, a template that expects a database column that is only half deployed, an API contract that shifted, will produce errors that are maddening to reproduce because they depend on which instance answered. Rolling deployments demand backward compatible changes, and that discipline is the real price rather than the infrastructure.

Rollback is also slower than people expect. A rolling deploy that is half done and going wrong has to be rolled back the same way it rolled forward, one instance at a time. That is why teams who care about recovery time often prefer the next strategy despite its cost.

Blue green deployment

Run two complete production environments. Blue serves live traffic while green sits idle. Deploy to green, test it properly with real production configuration, then move traffic across in one action. The old environment stays intact, so rolling back is flipping the same switch the other way.

What you buy is the fastest rollback available and the ability to test a fully deployed system before any user touches it. What you pay is double the infrastructure for the overlap, plus the awkward problem of shared state: the two environments almost always talk to the same database, so a schema change does not get to be blue or green. It is simply live, for both.

Not every blue green setup needs two servers. On a single box the same idea runs as two release directories with a symlink pointing at the live one, which is how most modern deploy tooling implements it and how zero downtime deployment works in practice on a VPS. We compare it directly against rolling in blue green vs rolling deployment.

Canary deployment

Send a small percentage of live traffic to the new version, watch the error rate and latency for that slice specifically, and widen it only if the numbers hold. If they do not, route the slice back and almost nobody noticed.

Canary is the only strategy on this list that reduces the blast radius rather than just the recovery time. Blue green still exposes everyone the moment you flip; canary exposes five percent. The cost is that it only works if you can do two things: split traffic by percentage, and read your metrics segmented by version. Without the second, a canary is just a slow rollout you are not actually watching, which is the most common way teams get this wrong.

You do not need Kubernetes for it. An nginx split_clients block hashing on the client address will hold a visitor on one side of the split and send a fixed percentage to a second upstream. The full mechanics, including what to measure and for how long, are in our canary deployment guide.

Shadow deployment, also called mirroring

Shadow deployment duplicates real production traffic to the new version without returning its responses to anyone. Users are served entirely by the current version; the new one gets the same requests in parallel so you can watch how it behaves under genuine load and real data shapes.

It is the only strategy with no user facing risk at all, which makes it the right tool for a rewrite of a critical service or a major infrastructure change where synthetic load tests have not convinced you. The costs are real though: you run a full duplicate, and any request with a side effect has to be neutralised or the shadow will send duplicate emails, charge cards twice or write the same row again. That plumbing is the reason shadow deployment stays rare outside large engineering teams.

Is A/B testing a deployment strategy?

Not quite, and confusing the two causes real problems. A canary and an A/B test both split traffic, but they ask different questions and end differently. A canary asks whether the new version is broken, measures errors and latency, runs for minutes to hours, and ends with everyone on one version. An A/B test asks which version people prefer, measures conversion or engagement, runs for days to weeks, and may end with both versions kept for different segments.

The practical consequence is that you should not use one mechanism for both. Deciding to abort a rollout on the same dashboard you use to judge a pricing experiment leads to slow rollbacks, because conversion data needs days to be meaningful and a broken release needs a decision in minutes.

How to choose a deployment strategy

If you are choosing for the first time, start at blue green implemented as release directories. It gives you the two properties that matter most, no downtime and an instant rollback, without asking you to run a second server or build traffic splitting. You can move up to canary later when traffic justifies it.

The part no strategy solves: database migrations

Every strategy on this list assumes you can run two versions of your application at once, or at least switch between them instantly. Your database does not cooperate with that assumption. There is one schema, both versions see it, and a rollback that flips application code back does not flip a dropped column back.

This is why the practical rule is to separate schema changes from code changes and make every migration backward compatible for one release. Add the column, deploy code that writes to both old and new, backfill, then deploy code that reads the new one, and only remove the old column a release later. It feels slow and it is the difference between a rollback that works and a rollback that makes things worse. We cover the mechanics, including which operations lock a table in Postgres and MySQL, in zero downtime database migrations.

What each strategy needs from your infrastructure

Strategies fail more often on missing prerequisites than on bad choices. Before you commit to one, check you have the pieces it assumes.

Every strategy above recreate needs a real health check, an endpoint that returns success only when the application can actually serve requests, not just when the process is running. Rolling and canary need a load balancer or proxy that respects it. Canary additionally needs metrics you can filter by version, which usually means tagging your application logs or metrics with a release identifier before you attempt your first canary rather than during it.

All of them need a deployment process that is scripted rather than manual, because a strategy is only as reliable as its worst execution at 2am. If yours still involves typing commands over SSH, deployment automation is the prerequisite, and deploying from git is the usual starting point. Teams in regulated industries should also wire the rollout into whatever documented change control their auditors expect, because a deployment strategy that nobody recorded is hard to evidence after the fact.

Finally, decide the rollback trigger before you need it. A written threshold, error rate above one percent for two minutes, is worth more than a room full of people debating whether the graph looks bad. Our deployment rollback guide covers what to prepare in advance.

Deployment strategies without Kubernetes

Most writing on this topic assumes a Kubernetes cluster, which is why so much of it reads as irrelevant if you run a handful of servers. Every strategy here predates Kubernetes and works without it.

Blue green on a single server is two release directories and a symlink, with a reload of PHP FPM or a process manager after the flip. Rolling across three servers is a loop that takes one out of the load balancer at a time. Canary is an nginx split_clients block pointing at two upstreams. Shadow is a mirrored location block. The concepts are about traffic and versions, not about any particular orchestrator, and container users can get the same properties from Compose and Swarm with the caveats we set out in Docker zero downtime deployment.

What Kubernetes genuinely adds is that rolling updates and health gated rollouts are the default rather than something you build. If you are not already running it, adopting an orchestrator to get a deployment strategy is a large price for something a symlink and a health check will give you.