Do you still schedule releases for late at night and put up a maintenance page? As your customer base grows across time zones, there is no quiet hour left, and every minute offline costs trust.
Zero-downtime deployments keep the old version serving traffic until the new one is proven healthy. Rolling releases replace instances gradually, blue-green deployments switch all traffic between two identical environments, and canary releases send a small share of traffic to the new version first. The right choice depends on your platform, risk tolerance and budget.
What causes downtime during a deployment?
Downtime usually happens when the old version stops before the new one is ready, when a database change breaks the running code, or when a faulty release reaches every user at once. Every zero-downtime strategy solves the first problem; the differences are in how they limit the impact of the third.
How do rolling deployments work?
A rolling deployment replaces instances of the old version with the new version a few at a time. The load balancer only sends traffic to instances that pass health checks. Kubernetes Deployments use this by default, controlled by settings such as maxSurge and maxUnavailable, and Amazon ECS services use rolling updates by default too.
- Pros: simple, built into most platforms, no extra environment needed.
- Cons: old and new versions run side by side during the rollout, and rolling back means rolling forward again with the old version.
How do blue-green deployments work?
You run two production environments. "Blue" serves live traffic while "green" receives the new version. After testing green, you switch traffic to it at the load balancer or DNS level. If something goes wrong, you switch back. AWS CodeDeploy supports blue-green deployments for Amazon ECS and EC2, and the same idea can be built with two target groups behind an Application Load Balancer.
- Pros: fast, clean rollback; you can test the new environment fully before users see it.
- Cons: needs capacity for two environments during the switch, and all users move at once.
How do canary releases work?
A canary release sends a small portion of traffic to the new version, watches error rates and latency, and increases the share step by step if metrics stay healthy. Tools such as Argo Rollouts and Flagger automate this on Kubernetes, AWS CodeDeploy offers canary and linear traffic shifting for Lambda and ECS, and weighted target groups or Route 53 weighted records can do it more manually.
- Pros: limits the impact of a bad release to a small group, and gives real production feedback.
- Cons: needs good monitoring and clear success criteria; more moving parts.
Which deployment strategy should you choose?
| Factor | Rolling | Blue-green | Canary |
|---|---|---|---|
| Setup effort | Low | Medium | Medium to high |
| Extra infrastructure | Little or none | Second environment during release | Small extra capacity |
| Rollback speed | Slower (redeploy) | Fast (switch back) | Fast (shift traffic back) |
| Blast radius of a bad release | Grows as rollout proceeds | All users after the switch | Small group first |
| Monitoring needed | Health checks | Health checks and smoke tests | Detailed metrics and alerts |
| Good fit | Most small and mid-sized apps | Releases needing full pre-release testing and instant rollback | High-traffic products where risk must be contained |
Many teams start with rolling deployments and add canary analysis as traffic and monitoring mature.
How do you handle database changes without downtime?
Because old and new code may run at the same time, database migrations must be backwards compatible. The usual approach is expand and contract:
- Expand: add new columns or tables without removing anything the old code needs.
- Deploy code that writes to both old and new structures, or reads from the new one with a fallback.
- Backfill existing data in batches.
- Contract: once nothing uses the old structure, remove it in a later release.
Avoid renaming or dropping columns in the same release that stops using them, and be careful with long-running locks on large tables.
Where do feature flags fit in?
Feature flags separate deployment from release. You can deploy code with a feature switched off, then turn it on for internal users, a percentage of customers or a specific region. Services such as LaunchDarkly or open-source options like Unleash make this manageable. Flags work well alongside any of the three strategies.
How do you decide when a release has failed?
Agree on rollback criteria before you deploy, not during an incident. Typical signals are a rise in error rates, slower response times for key endpoints, failed health checks or a drop in a business metric such as completed checkouts. For canary releases, these become the automated checks that decide whether traffic moves forward or back. For rolling and blue-green releases, the same criteria tell the person on duty when to stop and revert. Writing them down removes hesitation and arguments at a stressful moment.
What else do you need for safe releases?
- Proper health checks that test the application, not just that the process is running.
- Graceful shutdown so instances finish in-flight requests before stopping.
- An automated pipeline; see how to set up a CI/CD pipeline.
- Monitoring and alerts that tell you quickly if a release hurts users; see application monitoring and incident response.
Key takeaways
- Rolling releases are the simplest default; blue-green gives instant rollback; canary limits the blast radius.
- Database changes must be backwards compatible, using the expand and contract pattern.
- Health checks, graceful shutdown, feature flags and monitoring make any strategy safer.
Want releases your customers never notice? Get a DevOps and cloud quote from AppifyDevs, or see how simpler platforms support these strategies in Do you really need Kubernetes?