Recreate (Big Bang) Deployment
Concept
Recreate — also called big-bang deployment — is the simplest possible release strategy: shut down every instance of the old version, deploy the new version everywhere, then bring it back up. There is no intermediate state where old and new versions run side by side, no partial rollout, and no traffic-shifting logic to build or operate. For the duration of the cutover, the service is simply down. This isn't a strategy teams reach for because it's good at limiting risk — it's the strategy that falls out naturally when nobody has built anything more sophisticated, and it remains a legitimate choice specifically because of what it doesn't require: no second environment (unlike blue-green), no incremental batching logic (unlike rolling deployment), and no traffic-splitting infrastructure (unlike canary).
The tradeoff it makes explicitly is trading availability for simplicity and consistency. Because every instance moves from old to new atomically, there's never a moment where some callers hit v1 and others hit v2 — a property rolling and canary deployments give up in exchange for zero downtime. For systems where that version-consistency guarantee matters more than uptime during the deploy window (or where the old and new versions genuinely cannot coexist, such as an incompatible wire-protocol or schema change with no safe transition path), recreate is sometimes the only strategy that's actually correct, not just the laziest one.
Tradeoffs
| Dimension | Recreate / Big Bang | Rolling Deployment | Blue-Green |
|---|---|---|---|
| Downtime | Full downtime during cutover | None — old and new coexist during rollout | None — cutover is instant but environments are pre-warmed |
| Blast radius on a bad release | 100% immediately — no staged subset to catch it first | Capped by batch size, grows as rollout proceeds | Briefly 100% until detected, but rollback is instant |
| Version consistency during rollout | Perfect — never mixed old/new | Mixed old/new versions coexist for the rollout duration | Mixed only during the brief health-check window |
| Infrastructure cost | Lowest — single environment, no extra capacity | Low — no second full environment needed | Highest — double capacity during rollout |
| Implementation complexity | Lowest — no batching, no traffic-shifting logic | Moderate — needs batch sequencing and per-batch health checks | Moderate-high — needs two full environments and a cutover mechanism |
The core tradeoff is availability versus everything else: recreate is the cheapest and simplest strategy on every dimension except the one that usually matters most in production — it's the only one of the three that guarantees a visible outage window on every single deploy.
When to use / when not to
- Use recreate for low-stakes internal tools, batch/offline systems with no live traffic during the deploy window, or environments where a brief, planned outage is genuinely cheaper than the engineering investment in a zero-downtime strategy.
- Use it when old and new versions genuinely cannot safely coexist — an incompatible wire protocol or a schema change with no backward-compatible transition path — where "mixed old/new in flight" isn't a smaller risk than downtime, it's an outright correctness bug.
- Avoid it for any customer-facing service where availability during deploys is a real requirement — this is exactly the failure mode rolling, blue-green, and canary strategies exist to eliminate, and none of them cost dramatically more to operate once the tooling exists.
- If recreate is used, at minimum wire automated post-deployment verification with an explicit halt/alert on failure — since there's no smaller blast radius to fall back on, a failure here is already maximal, and the only lever left is detecting it fast.
Common pitfall
Treating recreate as a deliberate strategic choice when it's actually the default that happened because nobody built anything else. The pitfall isn't using recreate for a genuinely appropriate case (an offline batch job, an incompatible protocol change) — it's a team discovering, only after an outage, that their "deployment process" has always been full-downtime big-bang and nobody had actually decided that tradeoff was acceptable for a now-customer-facing service. The fix isn't "never use recreate" — it's making the choice explicit and revisiting it as the system's availability requirements change.
Engineering Lens
The Principal-level read on recreate deployment isn't "this is the bad option" — it's recognizing it as the correct baseline to compare every fancier strategy against, and being explicit about which specific property (zero downtime, capped blast radius, instant rollback) justifies the added complexity of rolling, blue-green, or canary for a given system. A team that can articulate "we use rolling deployment here because full downtime costs us $X/minute in lost transactions, and that's more than the cost of building batch-sequenced health checks" has made a real engineering decision; a team that's on recreate purely because nobody's revisited the deploy process since the service had ten users has an unexamined default, not a strategy.
Related
- Rolling Deployment
- Blue-Green and Canary Deployments
- Automated Post-Deployment Verification (unresolved)