What Is Zero-Downtime Deployment?

Quick answer
Zero-downtime deployment replaces the running version of your app without dropping requests or making users wait.
The strategies — rolling, blue-green, canary — differ in speed, risk, and how much infrastructure they need.
For a small app, the cheapest path is a platform with built-in rolling deploys plus readiness checks.

Why do normal deploys cause downtime?

A naive deploy stops the old process and starts the new one — a gap where nothing is listening, and every request fails or hangs. On a single server this gap can be seconds to minutes (build steps, migrations, startup). Users hitting the site in that window see errors. Zero-downtime deploys eliminate the gap by running old and new versions side by side, shifting traffic, and only stopping the old one after the new one is proven healthy.

What are the main strategies?

Rolling: replace instances one at a time while others keep serving — needs multiple instances but no extra infrastructure. Blue-green: run the whole new version (green) beside the old (blue), then switch traffic at the load balancer — instant switch and instant rollback, but doubles capacity during deploy. Canary: send a small percentage of traffic to the new version, watch metrics, then ramp up — lowest risk, but the most setup. All three require a health check and graceful shutdown to be genuinely seamless.

# docker compose: a minimal rolling deploy with health gates
# deploy:
#   replicas: 2
#   update_config:
#     order: start-first   # start new before stopping old
#     failure_action: rollback

Which strategy should a small app pick?

If you’re on a managed platform (Railway, Render, Fly.io, Vercel), rolling deploys with health checks are built in — that’s zero-downtime for free; just add a readiness endpoint and don’t stop the old version until the new one is healthy. Blue-green is worth it when you want instant rollback. Canary is for when you’re nervous about the change and want to watch metrics on real traffic. The strategy matters less than the fundamentals: health checks, graceful shutdown, and a rollback plan.

Where this bites vibecoders
The AI-generated deploy script that does kill-and-start works — until a real user hits the 30-second gap and reports ‘the site was down during deploy’. Vibecoders usually discover zero-downtime deploys the hard way because the assistant’s first deploy recipe is always the simplest (stop, start). The upgrade is mostly configuration: enable the platform’s rolling mode and add a health check, and deploys become invisible.

Where AI coding assistants get this wrong

Deploy scripts that stop the old process before the new one is ready, creating an outage window.
Zero-downtime claims without health checks, so the load balancer routes to a half-booted instance.
Rolling deploys that stop old instances faster than new ones become healthy.
No rollback path, so a bad deploy can’t be undone quickly.

Checklist

Add a readiness check so traffic only reaches healthy instances.
Use the platform’s rolling deploy mode or start-first ordering.
Keep old instances until new ones pass health checks.
Have a one-command rollback to the previous version.

FAQ

Do I need multiple servers for zero-downtime deploys?

For rolling deploys, yes — you need at least two instances so one can serve while the other updates. Blue-green technically needs only one old and one new instance, which is why it’s popular on single-VPS setups. A single instance with no second version can’t avoid a gap.

What is the difference between zero-downtime and a quick restart?

A quick restart still has a gap where nothing serves traffic — just a short one. Zero-downtime means requests are served continuously during the transition, because old and new versions overlap. Users can’t tell a deploy happened.