Deployment Strategies Overview

Every time you ship code to production, you're making a bet. You're betting the new version is better than the old one. Deployment strategies are how you manage that bet: controlling how much risk you take on, how fast you can recover if the bet is wrong, and how much of your user base gets exposed before you're confident.

This article gives you the complete picture: all five core strategies, when to use each, and a decision framework for choosing. For a deeper technical dive into any specific strategy, see the full Deployment Strategies article.

The Five Core Strategies

1. Recreate (Big Bang)

Shut down all old instances. Deploy new instances. Turn them on.

Downtime: Yes — the gap between shutdown and startup Rollback: Re-deploy the old version (takes time) Risk: 100% of users affected at once

This is the simplest strategy and it's perfectly acceptable for internal tools, batch jobs, dev environments, or any system where a maintenance window is acceptable. Don't overthink it for low-stakes deployments.

---

2. Rolling Update

Replace old instances one at a time (or in small batches). At any moment, some instances run the old version and some run the new. The load balancer routes traffic only to healthy instances.

Downtime: None (if done correctly) Rollback: Slow — you have to roll forward with the old version through each instance Risk: Partial — bad requests go to new instances only until they're replaced

The default strategy for most Kubernetes and AWS deployments. Works well as long as your old and new versions are API-compatible — both can run simultaneously against the same database and handle the same requests.

---

3. Blue/Green

Maintain two identical environments: blue (current production) and green (new version). Deploy to green, run smoke tests, then flip the load balancer or DNS. Blue stays warm for instant rollback.

Downtime: None Rollback: Instant — flip the load balancer back Risk: Very low — if green looks bad, no users are affected yet

The gold standard for zero-risk deployments. The catch: you need to run double the infrastructure, and database migrations must be backwards-compatible (both blue and green share a database).

---

4. Canary

Route a small slice of real traffic — typically 1-5% — to the new version. Monitor error rates, latency, and business metrics. Gradually increase the percentage if metrics look healthy.

Downtime: None Rollback: Fast — reduce canary percentage to 0% Risk: Limited to canary percentage × users

Canary is the best strategy when you need to validate a high-risk change on real user traffic before full rollout. The key requirement: your monitoring must be good enough to detect problems at low traffic volumes. If you can't tell the difference between normal variance and a bug at 2% traffic, canary doesn't help you.

---

5. Feature Flags

Deploy code to production but hide it behind a configuration flag. Enable for internal users first, then a percentage of users, then everyone. The deploy and the release are two separate events.

Downtime: None Rollback: Toggle off (instantaneous, no redeploy needed) Risk: Controlled — per-user, per-cohort, per-percentage

Feature flags decouple deployment risk (does the code run?) from release risk (do users see it?). You can deploy ten times a day and release features on your own schedule. Tools: LaunchDarkly, Unleash, Flipt, or a simple database-backed flag system.

Quick Comparison

Decision Framework

Start here when deciding which strategy to use:

Can you tolerate downtime? → No → Eliminate Recreate. Continue. → Yes → Use Recreate. Done.

Do you need instant rollback? → Yes → Use Blue/Green or Feature Flags. → No → Rolling Update is fine for most cases.

Do you need to validate on real traffic before full rollout? → Yes → Use Canary (or Feature Flags with a % rollout). → No → Rolling or Blue/Green.

Is this a high-risk feature that should be released separately from the deployment? → Yes → Feature Flags. Always. → No → Choose based on rollback and validation needs above.

Do you have a database migration? → Yes → Ensure it's backwards-compatible before any strategy that runs old and new code simultaneously (Rolling, Blue/Green, Canary). Add new columns before removing old ones. Never drop a column while old code is running.

How Real Teams Combine Strategies

The strategies aren't mutually exclusive. A common production pattern:

1. Feature flag the new feature — deploy the code safely, even to 100% of servers
2. Rolling update to deploy (zero downtime, low infrastructure cost)
3. Canary flag — expose to 1% of users via the feature flag system
4. Monitor 24 hours → ramp to 10% → 50% → 100%

This gives you the simplicity of rolling updates with the safety of canary releases and the rollback speed of feature flags.

Summary

Every deployment strategy is a different answer to the same question: how much risk are you willing to take, and how fast can you recover? Recreate is the simplest but riskiest. Rolling updates are the practical default for zero-downtime deployments. Blue/Green gives you instant rollback at the cost of double infrastructure. Canary limits blast radius by validating on real traffic gradually. Feature flags give you the ultimate control by separating deployment from release. Most mature teams combine rolling updates with feature flags as their default, reaching for blue/green or canary for high-risk changes.