Rolling Deployment: Updating in Batches Without Doubling Your Infrastructure

A rolling deployment updates a fleet of servers incrementally: a small batch of instances is taken out of the load balancer rotation, upgraded to the new version, health-checked, and returned to service — then the process repeats with the next batch until the whole fleet runs the new release. Because most of the fleet keeps serving users at every step, the application stays available throughout, and because the existing servers are reused, no duplicate environment is ever needed.

What it is

Rolling deployment (also called a rolling update or rolling upgrade) is the default strategy in most orchestration platforms — container orchestrators, auto-scaling groups, and managed instance groups all implement it natively. The fleet is divided into batches (a fixed number of instances, or a percentage such as 20% at a time). For each batch, the deployment system:

1. Removes the batch’s instances from the load balancer so no new requests reach them, and drains in-flight connections.
2. Installs the new version on those instances — or, in immutable-infrastructure setups, terminates them and launches replacements built from a new image.
3. Runs health and readiness checks against the updated instances.
4. Returns the healthy instances to the rotation, then moves on to the next batch.

If a batch fails its health checks, the rollout pauses instead of marching on — the remaining un-updated instances keep serving traffic on the known-good version while the team investigates.

Two tuning knobs govern the pace and safety margin: how many instances may be unavailable at once (the batch size) and how many extra “surge” instances may be launched temporarily to preserve full capacity while a batch is out of rotation. A modest surge allowance — one extra instance, or a few percent — is the most infrastructure a rolling deployment ever adds.

The economics: why rolling is the budget option

That last point is the strategy’s signature advantage. Rolling deployment upgrades the servers you already own, so its infrastructure cost is essentially the steady-state cost of production — at most a small temporary surge above 100% capacity. Blue-green deployment, by contrast, must stand up a second complete production environment, pushing peak capacity to roughly double for the duration of the release window. When an exam stem asks you to compare the infrastructure cost of the two strategies, the answer is that rolling requires little or no additional capacity because it updates the existing fleet in place batch by batch, while blue-green requires a full parallel environment.

The savings come with strings attached, covered next — cost is the reason teams pick rolling, and the trade-offs are the reason they sometimes shouldn’t.

What you give up: the rolling deployment trade-offs

Slow, awkward rollback. There is no idle old environment waiting to take traffic back. Undoing a bad rolling release means running another rolling deployment in reverse — pushing the previous version back through the fleet batch by batch. That takes roughly as long as the original rollout, during which the defective version keeps serving a shrinking share of users. Choosing rolling over blue-green means accepting exactly this: you trade the instant, flip-a-switch rollback for lower infrastructure cost.

Mixed versions in production. From the first batch until the last, old and new versions serve live traffic side by side. Every request might land on either one. This forces the same compatibility discipline as a canary: API contracts must work across both versions, message formats and cache entries must be mutually intelligible, and database schema changes must be backward compatible so old-version instances don’t break mid-rollout. Applications that can’t tolerate version coexistence — tightly coupled clusters, protocol-breaking changes — are poor rolling candidates.

Reduced capacity or slower rollouts. Instances in the batch being updated aren’t serving traffic. With no surge capacity, the fleet runs slightly below full strength during the rollout; with conservative small batches, the rollout takes longer. Either way, releases during peak traffic need headroom planning.

Failure exposure grows with each batch. A defect that passes health checks reaches more users as batches complete. Health checks verify that an instance is up, not that it is correct — which is why teams wanting metric-based judgment of real user experience layer a canary deployment in front of, or instead of, a plain rolling update.

Rolling vs in-place: batches vs everything at once

Rolling is sometimes lumped together with in-place deployment because both reuse existing servers rather than provisioning a new environment. The fundamental difference is sequencing across the fleet. An in-place deployment updates the servers directly where they run without a phased traffic strategy — effectively the whole fleet is upgraded in one operation, which normally requires taking the application down (or accepting broken service) during the update, since there is no untouched portion of the fleet left to carry traffic. A rolling deployment updates only a subset at any moment, deliberately keeping the remaining instances live and serving users, so the service as a whole never goes offline. Same servers, radically different availability story: in-place trades downtime for simplicity; rolling spends orchestration complexity to eliminate that downtime.

Factor	Rolling	In-place (all at once)
Servers updated at a time	One batch (subset of fleet)	Entire fleet in one operation
Availability during update	Maintained — untouched batches serve traffic	Typically requires downtime/maintenance window
Extra infrastructure	None, or small surge	None
Version mix during update	Old + new coexist temporarily	N/A — all instances change together
Rollback	Reverse rolling pass (slow)	Redeploy old version (service down again)

How the CV0-004 exam tests this

• Cost-comparison stems: which statement correctly compares rolling and blue-green infrastructure cost — rolling reuses the existing fleet (little to no extra capacity), blue-green doubles it.
• Trade-off stems: what a team accepts by choosing rolling over blue-green — slower, batch-by-batch rollback and a period of mixed versions, rather than an instant traffic flip to a standing old environment.
• Strategy-identification stems: “servers updated a few at a time while the rest continue serving users” describes rolling; distractors describe blue-green (parallel environment), canary (metric-gated small user slice), and in-place (whole fleet, downtime).
• Rolling vs in-place discrimination: the differentiator the exam wants is fleet sequencing — rolling upgrades subsets sequentially to preserve availability, while in-place upgrades every server in one pass with no live remainder to carry traffic.

Rolling is one of the four release strategies in the Deployment domain of the full CV0-004 study guide — expect to tell all four apart under time pressure, which is exactly what Cloud+ practice questions train.

Quick reference

• Fleet is updated in sequential batches; instances are drained, upgraded, health-checked, and returned to rotation.
• Availability is preserved because un-updated batches keep serving traffic the whole time.
• Cheapest zero-downtime strategy: no duplicate environment, at most a small surge above normal capacity.
• Rollback is slow — a reverse rolling pass — versus blue-green’s instant traffic flip.
• Old and new versions coexist mid-rollout, so APIs, data, and schemas must be cross-version compatible.
• A failed batch’s health checks should pause the rollout, leaving the rest of the fleet on the known-good version.
• Differs from in-place deployment by updating subsets sequentially instead of the entire fleet at once with downtime.
• Batch size and surge allowance tune the balance between rollout speed and capacity headroom.