Blue-green vs rolling deployments

What it means

A ready instance and a serving instance are not the same thing. Readiness describes whether an instance meets the deployment's readiness criteria; traffic assignment determines whether users reach it. This distinction matters most when a complete new pool is waiting beside the old one.

Here, Full serving fleet size means the size of one complete serving fleet, not the total number of instances across two pools. The comparison examines version overlap and the model's capacity assumptions. It does not compare measured performance, provider pricing or deployment commands.

Try it

Simulation: use the synthetic baseline below. First change only New schema also supports old code? to yes and inspect what changes without changing the counts. Then set Ready new-version instances to 6. Select Compare with baseline to place the current count beside the initial count; editing another input clears that comparison. The baseline and worked contrast remain readable without JavaScript; interactive controls require JavaScript. No deployment or external action is performed.

The initial result is 4 old + 2 new serving instance(s): rolling assigns two of the six serving slots to ready replacements, leaving four on the old version. STOP: old code may encounter an incompatible changed schema. Readiness alone does not establish safe overlap. The cutover control is not used for rolling.

Keep Strategy = rolling, Full serving fleet size = 6 and Switch all traffic to new pool? = no throughout this comparison. Only readiness and the supplied compatibility assumption change.

Reset restores Strategy = rolling, Full serving fleet size = 6, Ready new-version instances = 2, Switch all traffic to new pool? = no and New schema also supports old code? = no. It removes input errors and clears the comparison. It preserves your independent open or closed choices for each FAQ answer and About this model.

How it works

The key distinction is when readiness affects traffic. Rolling subtracts the ready new-version count from the declared fleet size to obtain the old-version count. Each ready replacement therefore changes the mix of serving versions. Blue-green keeps the full old pool serving before cutover; ready instances in the new pool do not yet contribute to the serving count.

A synthetic four-instance example makes the boundary visible. With blue-green, fleet size = 4, ready = 4 and cutover = no, the result is 4 old + 0 new serving instance(s). The new pool is complete but still inactive. With fleet size = 4, ready = 3 and cutover = yes, the result is STOP: new pool is incomplete. Requiring a full pool before cutover is this model's declared policy, not a universal deployment rule.

Separating traffic does not necessarily separate data. If both pools depend on shared state, changing its schema can affect the old serving code before any user traffic reaches the new pool. Accordingly, the model warns when compatibility is no, old instances remain and at least one new instance is ready—even if those new instances are inactive. This is a warning about a possible incompatible shared-schema change, not evidence that a migration occurred; the model has no migration timing or execution.

Worked example

This baseline is synthetic, not a captured production observation.

The result is 4 old + 2 new serving instance(s). The intermediate calculation is 6 − 2 = 4 old instances, with the two ready replacements counted as new serving instances.

The compatibility input is no while both versions remain in play, so the result also carries the schema STOP warning. All six serving slots being accounted for does not resolve that warning: capacity and the ability of old code to use changed shared state are different questions.

What changes when the condition changes

Set Ready new-version instances to 6 and New schema also supports old code? to yes. Keep Strategy = rolling, Full serving fleet size = 6 and Switch all traffic to new pool? = no.

The result is 0 old + 6 new serving instance(s). All six serving slots now count as new-version instances.

These two changes affect different parts of the result. Changing compatibility to yes while readiness remains at 2 removes the schema warning without changing the 4-old/2-new count. Increasing readiness to 6 then removes the old instances from the serving count. The final state does not establish that the earlier mixed-version steps were safe.

The cutover control remains unused for rolling. Asset retention, in-flight requests and actual rollback still need separate checks.

In practice

Use the comparison to decide what evidence your rollout needs. Rolling is a candidate when you can support and verify the mixed-version interval. This blue-green variant is a candidate when you can prepare a separate full pool and control the traffic switch. Neither is a justified choice merely because its final state contains only the new version.

Start with a read-only review of a service and environment you are authorized to inspect. Identify the serving pool, readiness criteria, shared-data dependencies, retained client assets and preserved prior release. The expected evidence is a documented account of which versions can serve at each stage and which shared state they can safely use. STOP planning the transition if compatibility is unknown or old code cannot use the changed shared state. Do not turn an unsupported assumption into a yes in the lab.

This page is not a deployment runbook. Before any real change, use an application- and platform-specific plan that identifies the exact authorized scope, preserves the before-state, defines verification and STOP conditions, and provides a tested rollback with verification of recovery. Validate mixed-version behavior in an authorized test environment rather than experimenting on production from these counts.

Keep traffic reversal and data recovery separate. Switching requests back does not undo a migration, and old code may no longer work with the resulting schema or data.

Limits and unknowns

The Simulation counts versions under fixed-capacity assumptions. Counts are not traffic percentages, measured throughput or proof of uninterrupted availability. It does not observe a real service, issue requests, change routing, run migrations or perform rollback. Browser asset references and in-flight requests remain outside its calculation.

Full serving fleet size has a range of 1–100; Ready new-version instances has a range of 0–100 and cannot exceed the fleet size. Invalid input removes the calculated outcome until you correct it or use Reset. A requested blue-green cutover with an incomplete new pool produces a visible STOP instead of a serving-count result; that branch does not establish schema compatibility.

There is no unknown option for the compatibility control. A selected yes is an input assumption, not a finding. If compatibility has not been established for your application, it remains unknown regardless of the displayed count. Likewise, the absence of a STOP warning does not prove that assets, clients, data recovery or the actual traffic switch are safe.

What to carry forward

Choose by the transition you can support: rolling requires confidence in mixed-version operation; this blue-green variant requires a separate ready pool and a deliberate traffic switch. Neither removes shared-state or recovery risks. Your next useful evidence is compatibility during the transition—not merely a successful check after every instance has been replaced.