Deployment Strategies: Rolling, Blue-Green, Canary, Flags, and Recreate

A deployment strategy determines how a new software version reaches users and how much risk the organization accepts while that change is happening. Rolling updates, blue-green deployments, canary releases, feature flags, and recreate deployments solve different operational problems. None is universally safest. The right choice depends on capacity, state, traffic control, compatibility, observability, rollback speed, and the amount of customer impact a failed change can create.

Modern platforms make these patterns easier to automate, but automation does not remove the need for design. Kubernetes supports RollingUpdate and Recreate strategies. AWS services support blue-green, canary, linear, and rolling patterns in different contexts. Feature flags can separate code deployment from user exposure. The important engineering decision is not which label sounds advanced; it is which failure mode your system can detect and recover from before the blast radius becomes unacceptable.

Recreate is simple because only one version runs

A recreate deployment stops the old version before bringing up the new one. The operational advantage is simplicity: there is no period in which old and new application versions must coexist. That can be valuable when two versions cannot safely share a database schema, a hardware resource, or an exclusive process.

The cost is downtime. Kubernetes documents Recreate as terminating existing Pods before creating the replacement set. That makes the strategy appropriate for internal tools, development systems, low-criticality workloads, or changes where mixed-version operation is more dangerous than a controlled outage. It is a poor default for customer-facing services that promise continuous availability.

Rolling updates preserve capacity but create a mixed-version window

A rolling deployment gradually replaces old instances with new ones. Availability can remain high because only part of the fleet changes at a time. Parameters such as surge capacity and maximum unavailable instances control how much extra infrastructure is used and how much capacity can disappear during the rollout.

The hidden requirement is backward and forward compatibility. For a period, version N and version N+1 may process traffic together. Database changes, message schemas, caches, sessions, and APIs must tolerate that overlap. A rolling strategy that looks safe at the infrastructure layer can still fail if application versions interpret shared state differently.

Database and message compatibility should be tested with the same seriousness as application health. A canary can look healthy while publishing events that older consumers cannot parse, or a rolling deployment can leave background workers on an older schema. Include downstream consumers in release validation when a change crosses service boundaries.

Blue-green separates environments to make cutover reversible

Blue-green deployment creates a complete new environment alongside the existing production environment. The green version can be validated before traffic is switched. If the new version fails quickly and the old environment remains intact, traffic can be redirected back with much less reconstruction than an in-place rollback.

The tradeoff is duplicated capacity and environmental discipline. Green must be representative enough that its validation means something. Data migrations, external integrations, secrets, background jobs, and stateful services can make “identical environments” difficult in practice. Blue-green is most powerful when infrastructure can be reproduced reliably and traffic routing is well automated.

Canary releases buy evidence with a small blast radius

A canary deployment sends a small portion of real traffic to the new version before wider rollout. The goal is to test the release under production conditions while limiting the number of users exposed to an unknown defect. If error rate, latency, business conversion, or another critical signal degrades, the team can stop the rollout before the majority of traffic moves.

Canary safety depends on measurement. A 5% traffic shift is not useful if the canary population does not exercise the risky code path or if teams cannot compare behavior quickly. Choose metrics that reveal both technical health and user outcomes. Automated gates should be conservative enough to halt on clear regression but not so noisy that every deployment becomes a manual investigation.

The safest teams also define a stop condition before the release begins. Decide which error rate, latency change, failed business transaction, or dependency signal should pause promotion. Precommitting to those conditions reduces the temptation to rationalize bad production evidence because a release is politically important or because the team has already invested significant time in it.

Feature flags separate code deployment from feature exposure

Feature flags allow code to exist in production while selected behavior remains disabled or limited to a target audience. This can reduce the coupling between the moment a binary is deployed and the moment a capability becomes visible. Product teams can expose a feature to employees, a percentage of users, a geography, or a specific tenant without rebuilding the application.

Flags are not free. Long-lived flags create branching complexity, make testing matrices larger, and can become hidden configuration dependencies. Teams need ownership, expiry dates, safe defaults, auditability, and a cleanup process. A flag should be treated as temporary operational code, not as an excuse to leave unfinished control paths permanently embedded in the system.

Feature exposure and infrastructure rollout should be monitored separately. A new binary can be healthy while a newly enabled feature fails for one segment. If dashboards only identify the application version and not the flag state or experiment cohort, operators lose the ability to connect symptoms to exposure. Release metadata should therefore include version, environment, flag state, and relevant traffic group where practical.

Rollback strategy must match the kind of change

Rolling back application code is easy only when state has not moved beyond what the previous version understands. Database migrations, irreversible data transformations, external side effects, and message-format changes can make a simple binary rollback unsafe. This is why mature delivery pipelines favor expandable schema changes, compatibility windows, idempotent operations, and explicit recovery procedures.

A strong CI/CD delivery process defines rollback before deployment. It should answer what signal triggers reversal, who or what can stop traffic movement, how state is protected, and how the system proves that the earlier version is actually healthy after the rollback.

A safe release needs more than infrastructure health checks. CPU and memory can look normal while a payment flow fails or a search result becomes incorrect. Deployment monitoring should include service-level indicators, application errors, dependency failures, queue depth, latency percentiles, user transactions, and the business events most closely tied to the changed behavior.

Version-aware telemetry is especially valuable. Logs, traces, metrics, and dashboards should make it possible to compare old and new versions during a rolling or canary release. Without that separation, teams can see that the service is unhealthy without knowing whether the new version is responsible.

Stateful systems make the choice harder. A stateless web tier can often run two versions safely, while a database schema, stream processor, or stateful protocol may require carefully sequenced compatibility. Techniques such as expand-and-contract schema changes let old and new application versions coexist by introducing backward-compatible structures first, switching application behavior later, and removing obsolete structures only after the old version is gone.

Choose a strategy by failure tolerance, not fashion

Use recreate when downtime is acceptable and version coexistence is unsafe. Use rolling when capacity must stay available and application versions can coexist. Use blue-green when fast traffic reversal and environment isolation justify duplicated capacity. Use canary when production evidence is important and traffic can be segmented. Use feature flags when exposure should be controlled independently from deployment.

These patterns can also be combined. A team might deploy a green environment, route a small canary percentage to it, and then use feature flags inside the new version. Complexity should buy a specific risk reduction. If operators cannot explain which failure each layer controls, the deployment system may be more complicated without being safer.

Capacity planning also changes by strategy. Blue-green may temporarily require nearly double the compute footprint. Rolling deployments use less extra capacity but can run below full service capacity if surge and unavailable limits are poorly chosen. Canary releases may need representative traffic at small scale, while low-volume services can struggle to generate enough observations for confident statistical comparison.

Practice the strategy before the high-risk release

The worst time to discover that rollback permissions, traffic controls, or dashboards are broken is during a production incident. Rehearse deployment and recovery with ordinary changes. Test alarm thresholds, verify that traffic can be shifted, confirm that previous artifacts remain deployable, and measure how long recovery takes.

Engineers pursuing the AWS Developer-to-DevOps path or the DOP-C02 exam encounter the same underlying principle: delivery is an operational system. Source control, automation, environment design, monitoring, and recovery have to work together. The best deployment strategy is the one your team can observe, stop, and recover with confidence.

Change communication matters even when deployment is fully automated. Operators, support teams, and incident responders should know which version is being promoted, what user behavior may change, which metrics are expected to move, and how to recognize a rollback. This context reduces confusion when a legitimate product change looks like a fault or when a real regression appears shortly after release. Safe deployment is technical control plus shared situational awareness.