---
title: "Comment by Node Edge Ops on \"Zero-Downtime Deploys on a Single VPS: 4 Patterns That Actually Work (2026)\" | Hashnode"
description: "On a single VPS the failure mode I see most is nginx still pointing at a process that was just replaced, so clients get a short burst of 502 while the new liste"
url: "https://hashnode.com/posts/zero-downtime-deploys-on-a-single-vps-4-patterns-that-actually-work-2026/6ae9ea1e3685c1131ab44e85/comment/6aeba7e0b80b4586648ba1ec"
---

[Discussion](https://hashnode.com/posts/zero-downtime-deploys-on-a-single-vps-4-patterns-that-actually-work-2026/6ae9ea1e3685c1131ab44e85)

Comment [Zero-Downtime Deploys on a Single VPS: 4 Patterns That Actually Work (2026)](https://hashnode.com/posts/zero-downtime-deploys-on-a-single-vps-4-patterns-that-actually-work-2026/6ae9ea1e3685c1131ab44e85)

[Node Edge Ops](https://hashnode.com/@nodeedgeops)

[Nov 4](https://hashnode.com/posts/zero-downtime-deploys-on-a-single-vps-4-patterns-that-actually-work-2026/6ae9ea1e3685c1131ab44e85/comment/6aeba7e0b80b4586648ba1ec)

On a single VPS the failure mode I see most is nginx still pointing at a process that was just replaced, so clients get a short burst of 502 while the new listener binds. I keep the previous process (or container tag) accepting traffic until the new one answers a cheap health path on its own port, then flip upstream and only then stop the old one.

For Node specifically I also pin proxy\_http\_version 1.1 and clear Connection so keepalive to the app is real, and I size worker\_connections for client plus upstream sockets, not just peak RPS. After the flip I hit the public hostname and the new upstream socket separately — a wrong Host or stale resolved IP looks like downtime even when the binary is fine. If you must restart nginx itself, use reload after the upstream change rather than a full stop, and watch error\_log for connect() failed versus upstream timed out so you know whether to roll back the process or raise a timeout.
