What is rolling update?
In our journey through Blue-Green and Canary deployments, we’ve looked at strategies that often require running two separate "fleets" of servers. But what if you don't have the budget to double your server count, or you’re running a massive cluster where moving 100% of traffic at once is too risky?
That is the Rolling Update. It is the "One-in, One-out" policy of the cloud. It is the default way modern platforms like Kubernetes and AWS Auto Scaling keep your software fresh without ever turning the lights off.
A rolling update replaces instances of the old version of your application with instances of the new version, one by one (or in small batches), until the entire fleet is updated.
At any given moment during the update, a portion of your users is on the old version, and a portion is on the new. The total number of servers remains (roughly) the same throughout the process.
The Analogy:
Think of Replacing the Lightbulbs in a Stadium.
Blue-Green: You build a second stadium next door with new bulbs and move the entire crowd over at halftime. (Expensive and overkill).
Rolling Update: An electrician walks around the stadium during the game. They unscrew one old bulb and screw in a new one, then move to the next. The stadium never goes dark, and by the end of the night, every bulb is new.
The Trigger: You push a new version of your container or code.
The Launch: The system starts one new instance (Version 2).
The Health Check: The system waits for the new instance to pass a "Health Check" (confirming the app is actually running).
The Swap: Once the new one is healthy, the system shuts down one old instance (Version 1).
The Loop: It repeats this process until 100% of the fleet is Version 2.
In 2026, you don't just "roll" blindly. You control the speed using two critical settings:
Max Surge: How many extra instances can be created above your target number? (e.g., "Start 2 new ones before killing any old ones" to ensure you never lose capacity).
Max Unavailable: How many instances can be "offline" at once? (e.g., "It's okay if 10% of my servers are down during the update").
Unlike Blue-Green, which requires you to pay for double the hardware during the switch, a Rolling Update only requires a tiny bit of "Surge" capacity. This makes it the most wallet-friendly way to deploy at scale.
If the first few "New" instances fail their health checks, the update stops automatically. You might have 10% of your fleet failing, but the other 90% is still running the old, stable version perfectly. This limits the "Blast Radius" of a bad bug.
Because it works directly with your Auto Scaling Group or Kubernetes Deployment, it handles the networking and load balancing automatically. You don't have to manually point traffic anywhere.
| Feature | Rolling Update | Blue-Green | Canary |
| Cost | Low (Minimal extra) | High (2x instances) | Low |
| Rollback Speed | Slow (Must "roll back" one by one) | Instant | Instant |
| Complexity | Simple/Automated | Medium | High |
| Downtime | Zero | Zero | Zero |
During a Rolling Update, two different versions of your code are running at the same time. * The Catch: Your database and your users' browsers must be able to handle both. If Version 2 changes the database in a way that breaks Version 1, your "Rolling" update will crash your "Old" servers. Always ensure your changes are backward-compatible.
The Rolling Update is the workhorse of cloud deployment. It’s balanced, cost-effective, and highly automated. While it’s not as "flashy" as a Blue-Green switch, it’s the most practical way to keep your applications evolving every single day without your users ever noticing a flicker.