Choosing between blue-green, canary, rolling, and recreate deployments is a platform engineering decision, not just a pipeline setting. This guide compares the trade-offs, shows how to estimate temporary infrastructure needs, and provides a repeatable method for selecting a strategy for each service.
Overview
A deployment strategy defines how a new application version reaches production and what happens to the old version during the transition. The right choice depends on more than whether a platform supports zero-downtime deployment. You also need to consider traffic control, rollback speed, database compatibility, observability, capacity, and the operational skills available to the team.
For infrastructure as code and platform engineering teams, the goal is to make these choices explicit and repeatable. A platform can provide safe defaults, reusable deployment modules, policy checks, and pipeline templates, while service teams select an approved strategy based on the service's risk and architecture.
| Strategy | Infrastructure cost | Traffic control | Rollback behavior | Operational complexity |
|---|---|---|---|---|
| Rolling | Usually low to moderate; old and new capacity overlap | Gradual by instance, pod, or batch | Reverse the rollout, subject to version compatibility | Moderate |
| Blue-green | High during overlap because two environments run together | Fast switch between complete environments | Usually fast traffic reversal | Moderate to high |
| Canary | Low to moderate, depending on the canary size and duration | Fine-grained percentage, segment, or header routing | Stop or reduce canary traffic | High without strong automation and observability |
| Recreate | Low; old capacity is stopped before new capacity starts | None during the replacement window | Requires redeployment of the previous version | Low, but downtime is expected |
No strategy removes release risk by itself. A fast rollback is useful only when application state, database changes, queues, caches, and external integrations remain compatible with both versions. Treat deployment design and data migration design as one release problem.
How to estimate
Start with a simple capacity and risk model rather than choosing a strategy from a platform menu. Estimate the resources required during the overlap period, then evaluate how much traffic and failure impact you can control.
1. Estimate peak temporary capacity
Use the following planning formula:
Temporary capacity = current production capacity + replacement capacity + rollout overhead
For a service running 10 pods with a replacement version that also needs 10 pods, a blue-green rollout may require approximately 20 pods while both environments are active. A rolling rollout may need less additional capacity, but the exact amount depends on the maximum surge and unavailable settings. A canary may begin with one or two additional pods, then grow as traffic and capacity increase.
Apply the same reasoning to CPU, memory, node groups, load balancers, IP addresses, persistent storage, and database connection limits. The cheapest strategy on paper can become expensive if a small cluster must add nodes to support the overlap.
2. Estimate rollback time
Break rollback into three intervals:
- Detection time: how long it takes to identify that the release is unhealthy.
- Decision and execution time: how long it takes to stop traffic, change a route, or redeploy.
- Recovery time: how long it takes for healthy instances, caches, queues, and dependent services to stabilize.
Blue-green deployments often make the traffic-switch step straightforward, provided the previous environment is still healthy. Canary releases can reduce exposure before rollback, but they require reliable automated signals. Rolling deployments may require reversing or completing a rollout, and rollback can be complicated if the two versions are not compatible. Recreate deployments should be selected only when a service can tolerate a planned interruption or has another availability mechanism.
3. Estimate exposure rather than relying on a single percentage
For a canary, exposure is not just the traffic percentage. Consider traffic percentage multiplied by the observation window, then add the importance of the affected users or requests. A 5% canary serving payment writes may represent more risk than a 25% canary serving a low-impact read endpoint. Segment by region, tenant, request type, or internal users when the platform supports it.
Define promotion gates before deployment begins. Useful signals include error rate, latency, saturation, queue depth, business transaction success, and dependency failures. A platform should make these gates visible in the pipeline rather than leaving the release engineer to interpret dashboards manually.
Inputs and assumptions
Document the inputs below in the service's deployment configuration or platform catalog. The values do not need to be perfect; they need to be explicit enough to support a consistent decision.
- Availability requirement: Can the service tolerate a short interruption, or must requests continue during deployment?
- Traffic architecture: Can the ingress, service mesh, gateway, or load balancer split traffic by percentage, header, region, or user group?
- Capacity headroom: How much CPU, memory, node, storage, and connection capacity is available for overlapping versions?
- Rollback compatibility: Can old and new application versions read the same data and process the same events?
- Observability maturity: Are logs, metrics, traces, and business-level health checks available for each version?
- State and background work: What happens to scheduled jobs, consumers, caches, sessions, and long-running requests during a switch?
- Automation level: Can the pipeline pause, promote, and roll back without ad hoc production commands?
- Cost boundary: Is temporary duplicate capacity acceptable for the duration of a release?
Database compatibility deserves special attention. A blue-green switch is not automatically safe when the new application requires a schema that the old application cannot read. Use an expand-and-contract migration pattern when both versions must operate during rollout; see the guide to zero-downtime database migrations for the sequence.
For Kubernetes, encode the selected behavior in reviewed manifests or Helm values, including replica counts, readiness probes, surge limits, disruption settings, and service routing. Validate the result in a production-like environment. A deployment can report that new pods are ready while the application is still failing a critical dependency check.
Worked examples
Example 1: A stateless API with limited spare capacity
An API runs 12 replicas during peak periods. The cluster has enough capacity for three additional replicas but not for a second full environment. The team has reliable request metrics and readiness probes, but traffic splitting is available only at the service level.
A rolling deployment is the practical default. Set a conservative surge limit, keep enough available replicas to protect normal traffic, and pause when error or latency thresholds are exceeded. A small canary may be possible if the gateway can route a selected subset of requests, but do not label a rollout “canary” when all traffic is still distributed randomly across old and new instances without measurable control.
Example 2: A customer-facing service with a costly failure mode
A service handles important transactions, has a compatible database migration process, and can run two complete versions for several minutes. The platform can switch traffic at the gateway and preserve the old environment.
Blue-green is a strong fit when fast reversal matters more than temporary capacity cost. Provision both environments through infrastructure as code, deploy and test green without public traffic, then switch the route through a controlled pipeline step. Keep blue available until post-release checks pass and the agreed rollback window expires. Confirm that background workers and scheduled jobs cannot run twice during the overlap.
Example 3: A high-volume service with mature observability
A team can route traffic by percentage and region. It has version-aware dashboards, distributed tracing, automated rollback thresholds, and a test suite for critical business actions.
Canary deployment can limit exposure while evidence is collected. Begin with a small, deliberate audience, observe both technical and business signals, then promote in stages. A canary checklist should include the initial audience, minimum observation time, promotion criteria, abort criteria, owner, and last known good version. If the service lacks trustworthy signals, use a simpler strategy until observability improves; canary adds control, but it also adds decisions.
A practical decision tree
- If planned downtime is acceptable and duplicate capacity is constrained, consider recreate.
- If downtime is not acceptable but traffic splitting is unavailable, use a carefully configured rolling strategy.
- If rapid whole-environment reversal is the priority and capacity is available, choose blue-green.
- If gradual exposure is valuable and routing plus observability are mature, choose canary.
- If database or event compatibility is uncertain, resolve that constraint before optimizing the deployment method.
When to recalculate
Revisit the deployment decision whenever the inputs change, not only after an incident. Recalculate temporary capacity when replica counts, resource requests, autoscaling limits, node pools, provider pricing, or workload peaks change. Reassess traffic controls after an ingress, gateway, service mesh, or load-balancing change. Platform capabilities and configuration names can also change across Kubernetes or deployment-tool versions, so validate reusable modules during upgrades.
Review the strategy before a major data-model change, a new region, a change in customer or transaction criticality, or a move from one deployment platform to another. After each release, compare the estimate with what actually happened: peak overlap, promotion time, rollback time, alert quality, and user impact.
To make the next rollout safer, record the service's chosen strategy, capacity assumptions, routing method, health signals, rollback command or pipeline action, and database compatibility requirements. Store those details beside the infrastructure code and keep them visible in the internal developer platform. A repeatable decision is more valuable than a universal default, because the best deployment strategy is the one that matches the service's failure modes, available capacity, and ability to observe and reverse change.
