Zero Downtime Deployments: Rolling, Canary, or Blue-Green?

Zero downtime deployments are achieved by routing traffic to a new version before removing the old one, with the three main strategies being rolling, canary, and blue-green. The best choice depends on your risk tolerance, infrastructure, and rollback speed requirements. This article explains how each works, their trade-offs, and how to decide.

Background: Why Zero Downtime Matters

Traditional deployments take the app offline, update files, and restart—causing minutes of downtime. For modern web services, even seconds of unavailability can lose revenue and frustrate users. Zero downtime strategies solve this by running two versions simultaneously and shifting traffic gradually or atomically. They also enable faster feedback loops, because you can test in production with real traffic before fully committing.

How Rolling Deployments Work

In a rolling deployment, you update instances one at a time (or in small batches) while the rest continue serving traffic. For example, with 10 servers behind a load balancer, you might take 2 out of rotation, deploy the new version, re-add them, then move to the next 2. The load balancer keeps sending requests to healthy instances, so there’s no full outage. However, during the process, both old and new versions are live simultaneously, so you must ensure backward compatibility—especially for database schema changes.

How Canary Deployments Work

A canary deployment routes a small percentage of traffic (e.g., 5%) to the new version while the rest stays on the old. You monitor metrics like error rates, latency, and user feedback. If all looks good, you gradually increase the percentage (10%, 50%, 100%) until the new version serves everything. This is the safest for high-risk changes because you limit exposure. It requires sophisticated traffic routing (e.g., via a service mesh or load balancer) and real-time monitoring to detect issues early.

How Blue-Green Deployments Work

Blue-green (also called red-black) runs two identical environments: “blue” (current) and “green” (new). You deploy the new version to green, run tests against it, then switch the router or load balancer to send all traffic to green. If something goes wrong, you switch back to blue instantly. The key advantage is atomicity—the switch is all-or-nothing, so there’s no mixed-version state. The downside is cost: you need double the infrastructure, and database migrations must be backward-compatible because both environments may access the same database during the transition.

How to Choose: Key Factors

Risk tolerance: Canary is best for high-risk changes; blue-green for low-risk with fast rollback; rolling for low-risk and cost-sensitive.
Infrastructure cost: Blue-green requires 2x resources; rolling and canary use the same pool.
Rollback speed: Blue-green is instant; canary is fast if you can route traffic back; rolling requires re-deploying the old version.
Database compatibility: All three require backward-compatible schema changes, but blue-green also needs the old and new app to work with the same DB during the switch.
Monitoring maturity: Canary needs robust metrics and alerting; blue-green needs good automated tests; rolling needs basic health checks.

Common Problems and Pitfalls

Each strategy has known failure modes. With rolling, you might accidentally route traffic to an instance that isn’t ready yet—fix by using readiness probes. Canary can mislead you if your sample isn’t representative (e.g., only testing a single region). Blue-green can break if the database schema is not compatible with the old version during the switch—mitigate by using expand-contract migrations. Also, all strategies require careful handling of long-running requests or WebSocket connections; you may need to drain connections gracefully.

Comparison Table: At a Glance

Here’s a quick comparison of the three strategies across typical dimensions:

Deployment speed: Rolling (slow, incremental) vs Canary (medium, staged) vs Blue-green (fast, atomic switch).
Rollback speed: Rolling (slow, re-deploy) vs Canary (medium, route back) vs Blue-green (instant, switch back).
Cost: Rolling (low) vs Canary (low) vs Blue-green (high, double infra).
Risk exposure: Rolling (medium, all at once) vs Canary (low, gradual) vs Blue-green (low, but all-or-nothing).
Complexity: Rolling (low) vs Canary (high, traffic splitting) vs Blue-green (medium, environment management).

Costs and Resource Considerations

Rolling and canary don’t require extra servers; they use the same capacity. Blue-green doubles your infrastructure costs because you run two full stacks. However, you can reduce costs by using auto-scaling to shrink the idle environment, or by using a cloud provider’s “environment” features that share resources. Also, consider the cost of a failed deployment: blue-green’s fast rollback may save money in the long run for critical services.

Safety and Best Practices

Regardless of strategy, follow these safety practices:

Always use health checks (readiness and liveness probes) to ensure instances are ready before receiving traffic.
Make database migrations backward-compatible—old and new code must work with the schema during the transition.
Automate rollback triggers based on metrics like error rate or latency.
Test the deployment process itself in a staging environment first.
For canary, define clear go/no-go criteria before starting.
For blue-green, verify the new environment with smoke tests before switching.

Frequently Asked Questions

Can I combine strategies?

Yes, many teams use canary within a blue-green environment—deploy to green, then gradually shift traffic to green instead of switching all at once. This gives you both atomic rollback and gradual exposure.

Which strategy is best for a small startup?

Rolling is often the simplest and cheapest to start with, especially if you have a small user base and can tolerate brief errors. As you grow and need faster rollback, consider canary or blue-green.

How do I handle database migrations with zero downtime?

Use expand-contract migrations: first add new columns/tables (old and new code work), then deploy the new code, then remove old columns. This works with all three strategies.

What is the difference between canary and A/B testing?

Canary is about reducing risk by gradually rolling out a new version to all users. A/B testing is about comparing two versions to measure business metrics; it may keep the old version for a longer period and doesn’t necessarily end with a full rollout.

Is blue-green worth the extra cost?

It depends on your downtime cost. If even a minute of downtime costs more than running double infrastructure, blue-green is worth it. For low-traffic or internal apps, rolling may be sufficient.

What tools support these strategies?

Kubernetes supports rolling updates natively, and canary via ingress controllers or service meshes like Istio. Blue-green can be implemented with load balancers or cloud services like AWS Elastic Beanstalk. Many CI/CD tools (Jenkins, GitLab CI) have plugins for these patterns.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →