A rolling deployment is a release strategy that replaces running instances of an application with the new version gradually, in small batches, while the remaining instances keep serving traffic. In DevOps practice, it is the most common way to ship updates without downtime, and it is the default update strategy for Kubernetes Deployments as well as for many cloud instance groups and container services.
The approach needs no duplicate environment. At any moment during the rollout, some instances run the old version and some run the new one, behind the same load balancer. This keeps infrastructure costs low, but it also means that both versions must be able to run side by side and that rollback is itself another gradual rollout.
How a rolling deployment proceeds
A rolling deployment repeats a simple cycle until every instance runs the new version. The orchestrator, whether Kubernetes, a cloud auto-scaling group or a deployment tool, takes a batch of instances out of rotation, updates or replaces them, waits until they are healthy and then moves on.
- Start new instances of the new version, or take a batch of old instances out of the load balancer.
- Wait for health checks, typically readiness probes, to confirm that the new instances can serve requests.
- Shift traffic to the healthy new instances and stop old instances with a graceful shutdown that drains open connections.
- Repeat with the next batch until the old version is fully replaced.
- Halt or roll back automatically if new instances fail health checks or a progress deadline expires.
The safety of the whole process depends on accurate health checks. If the readiness check only confirms that the process is running, broken instances join the pool and the rollout happily spreads a faulty release to the entire fleet.
Key parameters that control the rollout
A few parameters decide how fast the rollout proceeds and how much capacity is at risk. The table below uses Kubernetes names, but most platforms have equivalents.
| Parameter | Typical value | What it controls |
|---|---|---|
| maxSurge | 25 percent or 1 instance | How many extra instances may run above the desired count |
| maxUnavailable | 25 percent or 0 | How many instances may be out of service at once |
| minReadySeconds | 10 to 60 seconds | How long a new instance must stay healthy before it counts |
| Readiness probe | HTTP check every 5 to 10 seconds | When an instance may receive traffic |
| progressDeadlineSeconds | 600 seconds by default | When a stalled rollout is reported as failed |
| Termination grace period | 30 seconds by default | Time allowed to finish requests before shutdown |
Setting maxUnavailable to 0 and maxSurge to 1 gives the most conservative rollout: full capacity is kept at all times, at the cost of a slower release and a brief need for one extra instance. Higher values speed up large fleets but reduce spare capacity during the update.
Rolling deployment compared with other release strategies
Rolling updates are one of several zero-downtime deployment strategies. They differ in cost, rollback speed and how much of the user base is exposed to a faulty release.
| Strategy | Extra infrastructure | Rollback speed | Exposure to a bad release |
|---|---|---|---|
| Recreate | None | Slow, with downtime | All users, after an outage |
| Rolling deployment | Small surge capacity | Minutes, by rolling back | Grows with each batch |
| Blue-green deployment | A full second environment | Seconds, by switching traffic | All users at switch time |
| Canary deployment | A small extra group | Fast, by removing the canary | A small, measured share of users |
The main weakness of a plain rolling update is that it does not stop on its own for business-level errors. A release that passes health checks but raises the error rate or slows checkout will continue to roll. Teams therefore often combine rolling updates with automated metric analysis or move critical services to canary releases, which pause after each step to compare error rates and latency.
Requirements for safe rolling updates
Because two versions run at the same time, a rolling deployment places compatibility requirements on the application. The decision table below lists the situations that most often need extra planning.
| Situation | Risk | Recommended approach |
|---|---|---|
| Database schema change | Old instances fail on the new schema | Expand and contract migrations across releases |
| Changed API between services | Old clients call new servers or the reverse | Keep backward-compatible APIs for one release |
| Changed session or cache format | Users lose sessions when switching instances | Read both formats during the transition |
| Long-running connections | WebSockets or jobs are cut during shutdown | Longer grace periods and client reconnect logic |
| Stateful workloads | Ordered replicas break quorum | StatefulSet ordering and partitioned updates |
The expand and contract pattern is the standard answer for databases. First, a release adds new columns or tables without removing old ones; then the code switches to the new structure; finally, a later release removes what is no longer used. Each step is safe for both versions running side by side.
Common mistakes and failure modes
Most rolling deployment incidents come from configuration gaps rather than from the strategy itself. These problems appear frequently.
- Readiness probes that test too little, so instances with broken dependencies receive traffic.
- No graceful shutdown handling, which drops in-flight requests every time an old instance stops.
- Too little cluster capacity for the surge, leaving new instances pending and the rollout stuck.
- Assuming rollback is instant, although reverting is another full rollout that takes as long as the release.
- Ignoring post-deployment metrics, so a release that degrades users without failing health checks spreads everywhere.
In simple terms
A rolling deployment updates an application a few copies at a time. Large websites run many identical copies of their software. Instead of switching them all off at once, the team replaces a few, checks that they work and then continues.
It resembles renovating a hotel floor by floor while guests stay in the open rooms. The hotel never closes, but for a while some floors are new and some are old. Everything must still work together during that time.
A practical example
A payment API runs as 12 Pods in a Kubernetes cluster and receives traffic around the clock, so any downtime means failed transactions. The team configures its Deployment with maxUnavailable set to 0, maxSurge set to 2 and a readiness probe that checks the database connection, not only the process.
During a release, Kubernetes starts two new Pods, waits until they pass the probe for 30 seconds and then removes two old ones, repeating the cycle six times. The full rollout takes about eight minutes. In one release, the new Pods fail the probe because of a missing secret; the rollout stalls after the first batch, while the 12 old Pods keep serving. The team fixes the secret, and customers notice no interruption at all.