Rolling deployment
ROH-ling deh-PLOY-ment
Updating instances of an application one at a time (or in batches) so the service stays available.
A rolling deployment updates your application gradually, replacing old instances with new ones a few at a time. If you have 10 servers, you update 2, verify they are healthy, update 2 more, and continue until all 10 are running the new version. At no point does the entire application go down.
This is the default deployment strategy in Kubernetes. When you update a deployment, Kubernetes creates new pods with the new version and terminates old pods one by one. It waits for the new pod to pass health checks before terminating the next old one. If a new pod fails its health check, the rollout stops automatically.
The trade-off is that during the rollout, both the old and new versions are running simultaneously. This means your application must handle mixed-version traffic. API responses might come from the old or new version depending on which instance handles the request. Database schemas must be compatible with both versions. This constraint shapes how you write code and plan migrations.
Examples
A Kubernetes deployment rolls out a new version.
The deployment has 8 replicas running version 3.1. The engineer applies version 3.2. Kubernetes sets maxUnavailable to 1 and maxSurge to 1. It creates one 3.2 pod. Once healthy, it terminates one 3.1 pod. This repeats until all 8 pods run 3.2. The entire rollout takes 12 minutes. At peak mixed state, 4 pods run 3.1 and 4 run 3.2. No downtime occurs.
A rolling deployment detects a bad version.
During a rolling update, the third new instance fails its readiness check. Kubernetes pauses the rollout. Five instances run the old version and two run the new version. The engineer examines the failing pod's logs, finds a misconfigured environment variable, fixes it, and pushes a corrected version. Kubernetes resumes the rollout from where it paused.
A team manages mixed-version compatibility during rollouts.
Version 4.0 changes the API response format. During a rolling deployment, some requests hit 3.9 instances and others hit 4.0. Clients would receive inconsistent response formats. The team adds a version header to responses and makes 4.0 support both formats. After all instances are on 4.0, they schedule the old format's removal for version 4.1.
In practice
Read more on the blog
Frequently asked questions
What is the difference between rolling deployment and blue-green?
A rolling deployment gradually replaces instances. At any point, both old and new versions are serving traffic. Blue-green maintains two complete environments and switches all traffic at once. Rolling deployments use fewer resources (no duplicate environment) but have a mixed-version window. Blue-green has instant rollback but costs more in infrastructure. Rolling is the default in Kubernetes. Blue-green is simpler conceptually.
How do you handle database migrations with rolling deployments?
Use the expand-contract pattern. First, expand: add the new column or table without removing anything. Deploy the code that uses the new schema. Once all instances are updated, contract: remove the old column or table. Never change and remove in the same deployment because old instances still running during the rollout need the old schema. This adds an extra deployment step but prevents breakage.
Related terms
A deployment strategy using two identical environments to enable instant cutover and rollback.
Gradually rolling out a new version to a small subset of users before making it available to everyone.
The process of releasing code to servers where users can access it.
An open-source system for automating the deployment, scaling, and management of containerized applications.
Lightweight, portable packages that bundle application code with all its dependencies.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.