Zero-Downtime Deployments with Node.js

Shipping multiple times a day only works if deploys do not take the API offline. On production Node.js services I have used rolling deployments, readiness probes, and backward-compatible API changes together so traffic never hits a dead instance.

Why zero downtime matters

A hard stop-and-start deploy causes:

• Dropped connections and 502/503 errors at the load balancer
• Failed payments or half-written workflows
• Spikes in support tickets during the deploy window

Users should not notice that you released v1.2.1.

Practical checklist

1. Health endpoints — /health (liveness) and /ready (readiness after DB/migrations). The orchestrator only routes traffic when ready is true.
2. Rolling update — Replace instances one at a time (or in small batches). Keep enough replicas so capacity stays above peak load.
3. Graceful shutdown — On SIGTERM, stop accepting new requests, finish in-flight work, then exit. Node: close the HTTP server and drain the event loop.
4. Backward compatibility — Old mobile apps may still call v1 fields. Add fields; do not remove or rename without versioning.
5. Database migrations — Expand first (add column nullable), deploy code, then contract (remove old column) in a later release.

Node.js specifics

• Use cluster mode or multiple pods; one process crash should not kill the service.
• Set reasonable keep-alive and timeout values so the LB does not send traffic to a draining pod.
• Log deploy version in structured logs to correlate errors with releases.

Measuring success

Track error rate and P99 latency during deploy windows. If errors jump only when you ship, fix the deploy strategy before adding features.

Takeaway

Zero downtime is a process plus architecture problem: compatible APIs, graceful shutdown, and orchestration that respects readiness. Get this right once and every future release is less stressful.