Deployment doesn't end when git push does: it ends when you're certain you can go back in under a minute. The difference between teams deploying daily calmly and teams deploying Friday 6pm sweating isn't talent — it's consciously chosen strategy. Here are the four, with real costs.
Recreate: the one you should NOT use (but everyone starts with)
Stop old version, start new one. Zero extra infrastructure, zero complexity... and zero availability during the swap. Acceptable only for hobby projects or internal systems with maintenance windows. If your API serves real clients, keep reading.
Rolling: the Kubernetes standard
Deploy in batches: 25% of instances updated → health verified → next batch, while old ones drain traffic. Service never stops responding; capacity dips temporarily (4 replicas, 25% batch = operating at 75% for minutes).
Fine points separating good rolling from bad:
- Readiness vs liveness: only route traffic to ready pods (readiness probe), but restart dead ones (liveness). Confusing them = requests to still-warming instances.
- Graceful shutdown: on SIGTERM, the old instance must finish in-flight requests before dying (
terminationGracePeriodSeconds). Without this, 502s on every deploy. - Backward-compatible migrations: for minutes v1 and v2 coexist against the SAME database. Every migration must be additive (add nullable columns; never rename/drop in the same step).
Kubernetes does this natively (strategy: RollingUpdate); Docker Compose needs manual orchestration or tooling above.
Blue-Green: two full environments, instant switch
Two identical stacks: blue (current production) and green (new version). Deploy and test green completely —without touching production— then the load balancer switches all traffic at once. Rollback = point at blue again, seconds.
Honest advantages:
- Smoke tests against the REAL environment BEFORE switching.
- Instant trivial rollback.
- Consistent version for all users (no version mixing).
The price: double infrastructure during deploys (or permanently), plus inherited migrations problem: if green requires new schema, blue can't run against that DB anymore. Escape pattern: expand-migrate-contract across separate deploy phases.
Ideal for: mid-size apps on VPS/cloud with budget to duplicate, or where version consistency matters more than savings.
Canary: progressive percentage with judgment
Send the new version 1% of traffic, watch real metrics (errors, p95 latency, conversions), raise to 10%, 50%, 100% if nothing degrades. It's the only strategy validating against REAL traffic before committing — canaries detect problems no staging replicates: real load, weird data, unexpected usage patterns.
Serious technical requirements:
- Weighted routing (service mesh, ingress controller, or CDN edge).
- Sticky sessions if state lives in memory (or externalized state — required anyway).
- Automatically compared cohort metrics — eyeballing dashboards turns canary into theater.
It's the default at giants (Netflix, Google) precisely because their volume makes even 0.1% statistically meaningful. For a small SaaS a 5% canary may take hours accumulating signal — blue-green often performs better there.
Feature flags: decoupling deploy from release
The technique crossing all previous ones: new code ships deployed BUT switched off, controlled by a runtime-evaluated flag. "Release" becomes flipping a switch, instantly reversible, no redeploy.
Where they shine: gradual launches per user cohorts, A/B testing, kill switches for risky features, decoupling deploys from marketing (code ready Monday, announcement Thursday). The cost: flag debt if nobody cleans up — deletion discipline mandatory.
The rollback you never rehearsed
Every strategy above fails if rollback is theoretical. Standard test: once a month, quiet hours, do a REAL rollback of the latest deployment and time it. Two typical findings:
- Code rollback is easy; DATABASE rollback doesn't exist if yesterday's migration was destructive. Hence the mantra: expansive migrations first, contraction weeks later.
- Old artifacts must exist: keep versioned Docker images and prior builds — rollback via git redeploy takes minutes; rollback swapping image tag takes seconds.
Our GitHub Actions workflow covers the automation piece (CI + build + publish), and if your target is your own VPS, the self-hosting guide shows how compose and healthchecks fit this model.
FAQ
Which do I pick for my project? Quick heuristic: hobby/internal → recreate accepting downtime; small-medium SaaS on cloud → rolling (blue-green on VPS); big product with mature metrics → canary. And feature flags whenever complexity budget allows.
Does zero-downtime mean zero errors? No: means no service interruption. v2's own bugs will arrive anyway — that's what canary and flags protect against, not topology.
Does database deploy together with app? Never in the same step. Golden rule: every deployment must run against the previous schema version (backward compatibility) — it's what makes ALL the strategies above possible.
Automate your CI/CD pipeline with our GitHub Actions Generator, free and right in your browser.