← All posts
July 24, 2026·3 min read·Tutorials

Deploy a Node.js App to a VPS in 2026

A complete, no-nonsense walkthrough for deploying a Node.js app to a bare Ubuntu VPS: Docker, a reverse proxy, HTTPS, and zero-downtime deploys.

DeployOS Team · Engineering

Deploying a Node.js app to a VPS still scares off a lot of developers who grew up on Heroku or Vercel. That's mostly because most tutorials stop at "npm start" and never explain the part that actually matters: keeping the app alive, routed, and secure after you close the terminal.

Here's the real checklist, in order.

1. Provision the box

Any $5-$12/mo Ubuntu 22.04+ VPS works — Hetzner, DigitalOcean, Contabo, Vultr. You don't need Kubernetes for a single app. You need SSH access and a public IP.

2. Install Docker

Docker solves the "works on my machine" problem permanently. Install it with the official convenience script, add your user to the docker group, and confirm with docker run hello-world.

3. Put a reverse proxy in front of everything

This is the step most tutorials skip, and it's the one that bites you later. Running your app on port 3000 and calling it done works for exactly one app. The moment you want a second app, or HTTPS, or a real domain, you need something in front — Traefik or Caddy — that terminates TLS and routes by hostname.

Traefik in particular can watch Docker labels and auto-configure routes as containers start, which means adding app #2 later is a compose file, not an afternoon of nginx.conf archaeology.

4. Get HTTPS without touching certbot

Point your domain's A record at the VPS, add a couple of Traefik labels to your compose file, and Let's Encrypt certificates issue and renew themselves. No cron jobs, no manual renewal.

5. Deploy without downtime

The naive version — SSH in, git pull, restart — takes your app offline for however long the restart takes. A slightly less naive version builds the new image, starts it alongside the old one, waits for a health check to pass, and only then swaps the route. That's the difference between "deploy" and "deploy without your users noticing."

6. Have a rollback plan before you need one

The first bad deploy always arrives at the worst time. Tag your images by commit hash and keep the last few around, so rollback is "point the route back at the previous image," not "git revert and rebuild under pressure."

Where this gets tedious

Every step above is one-time-setup-able, which is exactly why so many people wrap it in a script (or never bother, and just SSH in and pray). If you'd rather skip the yak-shaving, this whole flow — Docker, Traefik, HTTPS, zero-downtime rollout, one-click rollback — is what DeployOS automates from a desktop app: point it at a repo and a VPS, and it does steps 2 through 6 for you, on infrastructure you already own.

Your own deploy platform, on a $5 server.

Deploy from GitHub to your own server in one click free download, no account needed.

Download DeployOS