Your Deploy Strategy Matters Less Than You Think
Most engineering teams spend weeks debating which deploy strategy to adopt — Rolling, Blue/Green, Canary — as if the choice alone were the deciding factor between a smooth deploy and a 3am Friday firefight in production.
It isn’t.
The strategy is the envelope. What determines whether your deploy works or blows up are the parameters: readiness delay, warmup time, connection draining, batch size. Details most teams configure on autopilot — or worse, leave at default.
This guide covers every major strategy, each with an interactive simulation you can tweak and break. But the point isn’t to pick the “best” one — it’s to understand why none of them save you on their own.
Important: the strategy alone does not guarantee zero downtime. Readiness/health checks, warmup, and connection draining settings can still drop requests even with Rolling, Blue/Green, or Canary if they are configured too aggressively.
Recreate
The old version (v1) is completely shut down before the new version (v2) starts. No overlap, no coexistence. Just stop everything and start again.
How it works:
- Stop all v1 instances
- Wait for full shutdown
- Start all v2 instances
- Resume traffic
Where it makes sense:
When you can’t have two versions running simultaneously — maybe due to database schema changes, license constraints, or stateful processes that don’t support concurrent versions.
| Pros | Cons |
|---|---|
| Maximum simplicity | Causes downtime |
| No version conflicts | Users lose access during deploy |
| Clean state transition | Rollback requires re-deploy |
deploy config✓ safe
Rolling
Version B replaces version A gradually, instance by instance (or in batches), until the entire environment is updated.
How it works:
- Take one (or a batch of) v1 instances out of the load balancer
- Replace them with v2
- Route traffic to the new instances
- Repeat until all instances are v2
The catch: Your application (especially the database) must support two different versions running simultaneously. API contracts, database schemas, feature flags — all need to be backwards compatible during the transition window.
Parameters like batch size, max unavailable, and minimum active instances matter too. If you let too many instances leave at once, you can create bottlenecks or even downtime despite using a rolling update.
| Pros | Cons |
|---|---|
| Zero downtime | Slow deploy process |
| Industry standard | Requires backward compatibility |
| Low infrastructure cost | Slow rollback |
deploy config✓ safe
strategy parameters
Blue/Green
Version B (Green) is deployed to an isolated but identical parallel environment to version A (Blue). After testing on Green, traffic is switched instantly at the load balancer from A to B.
How it works:
- Deploy v2 to the Green environment (Blue keeps serving traffic)
- Run smoke tests against Green
- Switch load balancer from Blue → Green
- If something breaks, switch back instantly
The expensive part: You’re paying for double infrastructure throughout the process. And database schema changes are a nightmare — both environments need to work with the same data layer.
| Pros | Cons |
|---|---|
| Zero downtime | Double infrastructure cost |
| Instant rollback | DB migrations are complex |
| Full pre-production testing | Sync between environments |
deploy config✓ safe
Canary
Version B is released to a small subset of users (e.g., 5%). If health metrics (error rate, latency, CPU) look normal, traffic is gradually increased in steps until reaching 100%.
How it works:
- Deploy v2 alongside v1
- Route 5% of traffic to v2
- Monitor metrics (errors, latency, saturation)
- If healthy, increase to 25% → 50% → 100%
- If metrics degrade, roll back to 0%
This is how most large-scale systems deploy today. It limits blast radius — if v2 has a bug, only 5% of users are affected before you catch it.
| Pros | Cons |
|---|---|
| Real production testing | High complexity |
| Limited blast radius | Requires observability tools |
| Data-driven confidence | Slow total deploy time |
deploy config✓ safe
strategy parameters
Canary ≠ A/B Testing: The infrastructure is similar — splitting traffic between versions — but the goals are opposite. Canary validates the technical health of the new version (error rates, latency, saturation). A/B testing validates a product hypothesis (which variant converts more, engages more, retains more). Canary is an engineering decision; A/B is a product decision. They often run on the same infrastructure but answer completely different questions.
Shadow
Version B runs in parallel and receives a copy (mirror) of all traffic going to version A. Version B’s responses are monitored by developers but ignored by end users — they always see v1’s response.
How it works:
- Deploy v2 alongside v1
- Mirror all incoming requests to both
- Users receive responses only from v1
- Compare v2’s responses, latency, and behavior
- When confident, promote v2 via another strategy
Critical detail: You must mock external side effects. If v2 processes a mirrored payment request, it should not actually charge the user’s card. Same for emails, webhooks, and any write operations to shared databases.
| Pros | Cons |
|---|---|
| Zero user risk | Very complex and expensive |
| Real load testing | Must mock all side effects |
| Catch regressions before production | Double infrastructure |
deploy config✓ safe
This isn’t about tools
The simulations above show a load balancer routing traffic to instances. But that’s just one level of abstraction.
The same patterns apply at completely different scales:
| Level | ”Load Balancer" | "Instance” | Example |
|---|---|---|---|
| Process | Process manager | Worker/thread | PM2, Gunicorn, Puma |
| Container | Service mesh / Ingress | Container | Kubernetes, ECS, Docker Swarm |
| Instance | ALB / Nginx / HAProxy | VM or server | AWS EC2, GCP Compute, bare metal |
| Region | DNS / Global LB | Entire region | Route 53, Cloudflare, GCP GLB |
A “Canary deploy” can mean:
- routing 10% of threads to the new code within a single machine
- routing 10% of pods to the new version within a Kubernetes cluster
- routing 10% of global traffic to an entire region running the new version
The mechanics are the same. What changes is the blast radius — how much of the system is affected if something goes wrong.
In the simulations, we use “instances” and “load balancer” as generic vocabulary. Mentally substitute the abstraction level that makes sense for your context.
Configuration matters more than strategy
The difference between a safe deploy and a disaster is 3 seconds of readiness delay.
Here’s the central thesis of this article: the belief that choosing Rolling or Canary automatically protects against downtime is dangerous. It doesn’t. With aggressive settings, even the “safest” strategy will drop requests.
Consider these scenarios:
Rolling with readinessDelay = 0:
You remove a v1 instance, bring up v2, and the load balancer routes traffic immediately — before the application is actually ready. Result: 502 errors during the startup window. Multiply that by each batch and you get a cascade of silent degradation.
Blue/Green with warmupTime = 0:
Traffic switches instantly to the Green environment, but Green is still warming up its connection pool, JIT, or cache. In the first few seconds, latency spikes and timeouts start appearing. The “instant rollback” helps — but the requests in that window are already lost.
Canary with very short bootTime:
The canary pod joins the pool before it can respond correctly. Even at just 5% of traffic, if your system handles millions of requests per day, 5% is a lot of failed requests.
The good news: you can test this right now. Go back to the simulations above, set the safety parameters (readiness delay, warmup, drain time) to aggressive values, and watch what happens to the requests. This is the best way to internalize why configuration matters more than the choice of strategy.
Comparison Table
| Strategy | Downtime? | Rollback Speed | Infrastructure Cost | Complexity |
|---|---|---|---|---|
| Recreate | Yes | Slow | Low | Low |
| Rolling | No | Slow | Low | Medium |
| Blue/Green | No | Instant | High (2x) | Medium-High |
| Canary | No | Fast | Medium | High |
| Shadow | No | N/A (no prod impact) | High (2x) | Very High |
The elephant in the room: database migrations
Every deploy strategy that keeps two versions running simultaneously (Rolling, Blue/Green, Canary) hits the same wall: the database must be compatible with both versions.
Adding a column? v1 must work with it present. Renaming a field? v1 will break if the old column disappears. Dropping a table? Impossible until v1 is completely gone.
The standard solution is the expand-contract pattern (also called “parallel change”):
Phase 1 — Expand: add the new structure (column, table, index) without removing the old one. Deploy v2 writing to both. At this point, v1 and v2 coexist without conflicts.
Phase 2 — Migrate: backfill data from the old structure to the new one. Ensure the new structure is the source of truth.
Phase 3 — Contract: remove the old structure. This is only safe when v1 no longer exists anywhere.
In practice, each phase is a separate deploy. A “simple” column rename becomes three sequential deploys. This is exactly why mature teams invest in feature flags and reversible migrations — because the deploy itself is only part of the story.
The deploy spectrum
The five strategies aren’t isolated choices — they form a spectrum. From left to right, operational complexity and infrastructure cost increase, but risk to end users decreases.
Simple
Lower cost / Higher risk
Complex
Higher cost / Lower risk
Recreate
Total downtime
Rolling
Gradual update
Blue/Green
Exact copy, doubles cost
Canary
Percentage routing
Shadow
Mirrored traffic
No strategy is universally better. The sweet spot depends on your team size, service criticality, and observability maturity.
Which one should you use?
Start simple. If you’re a small team with a single service, Rolling updates will serve you well. As your system grows in complexity and user base, graduate to Canary releases.
Blue/Green shines when you need instant rollback guarantees — critical for financial systems or healthcare applications where even seconds of degraded service matter.
Shadow deploys are for major refactors — swapping databases, rewriting core services, or migrating to a new architecture. The investment in infrastructure and mocking is worth it when the stakes are highest.
How the best teams combine strategies
In practice, mature teams don’t use just one strategy. The typical pipeline combines several, each optimized for a different type of change:
| Type of change | Strategy | Why |
|---|---|---|
| New feature (code) | Canary → gradual promotion | Limits blast radius; fast rollback based on metrics |
| Critical hotfix | Rolling with batch of 1 | Speed + sequential validation |
| Database migration | Blue/Green + expand-contract | Instant rollback if the migration fails |
| Core service rewrite | Shadow → Canary | Validate with real traffic at zero risk, then promote gradually |
| Infrastructure change | Regional Blue/Green | Switch entire regions with immediate fallback |
A real-world pipeline might look like:
- Dev pushes → CI runs tests
- Automatic deploy to Canary 5% in production
- Automated monitoring for 10 minutes (error rate, p99 latency, saturation)
- If healthy: gradual promotion 25% → 50% → 100%
- If degraded: automatic rollback to v1
- For database migrations: separate Blue/Green, with the expand phase deployed days earlier via Canary
Your deploy strategy matters less than you think. Execution matters more than you imagine. The secret isn’t choosing the “right” strategy — it’s having the operational maturity to make any strategy work.