# Deployment Strategies Visualized
Table of Contents
There’s no universal deployment strategy let’s understand the most common deployment strategies.
Recreate (Big Bang)
This is the “turn it off and on again” of deployments. You stop all instances of the old version, then start the new one. Yes, there’s downtime. No, that’s not necessarily bad. If your users can tolerate a maintenance window, why overcomplicate things?
v1
v1
v1
Step 1 of 3
Rolling Deployment
Instead of switching everything at once, you update instances one by one (or in small batches). Traffic keeps flowing to healthy instances throughout the process.
For a brief period, you’ll have both v1 and v2 running simultaneously. If your API and DB isn’t backward compatible, you might have a bad time. You can mitigate this by versioning you APIs and applying the expand and contract pattern for DB migrations.
v1
v1
v1
v1
Step 1 of 6
Instances update sequentially, zero downtime but mixed versions temporarily
Blue-Green Deployment
This strategy keeps two identical environments: Blue (what’s currently live) and Green (the new version waiting in the wings). Once you’ve validated Green, you flip the switch and all traffic moves over instantly.
The rollback is straightforward: Just point traffic back to Blue. Done. The downside is you’re paying for two environments.
Step 1 of 2
Traffic switches between environments, instant rollback capability
Canary Deployment
Named after the canaries miners used to detect toxic gases, this strategy sends a small percentage of traffic to the new version first. If those users don’t experience issues, you gradually increase the percentage.
You need solid metrics to know if that 5% of traffic is happy or not. Error rates, latency percentiles, business metrics, pick your signals and watch them closely.
Step 1 of 6
Progressive Rollout
Think of this as canary deployments with autopilot. Instead of manually deciding when to increase traffic, you define gates: “if error rate stays below 1% for 10 minutes, proceed to the next stage.”
Step 1 of 5
Automated gates control progression based on error rates, latency, etc.
Choosing Your Strategy
The right deployment strategy depends entirely on your application’s needs. There’s no one-size-fits-all answer, and you’re not locked into a single approach, these strategies can be mixed and matched.
Consider what matters most for your application:
- Can you tolerate downtime? Recreate deployments are simple and simplify version conflicts.
- Need zero downtime? Rolling, blue-green, canary, and progressive all keep your service available.
- How fast must you rollback? Blue-green offers instant rollbacks; rolling deployments take longer.
- Can you afford extra infrastructure? Blue-green doubles your resource cost; rolling uses about the same capacity.
- How mature is your monitoring? Canary and progressive require solid observability to be effective.
- What’s your risk tolerance? Canary and progressive let you test with a subset of users first.
You can also combine strategies. For example, use rolling deployments for routine updates, but switch to canary for major changes. Or use blue-green for your API while doing rolling updates on your workers.
