Disclosure: This guide contains affiliate links. If you sign up through them, First Bridge Consulting may earn a commission at no extra cost to you. We only recommend platforms we actually deploy on for client projects — the rankings here are not for sale.
Hosting a Node.js app is not like hosting a static site. A real Node backend needs a persistent process that stays alive between requests, often holds WebSocket connections, runs background jobs, and talks to a database. That rules out cheap shared hosting and changes which platforms are actually viable. This guide covers where to host a Node.js app in 2026, organized by what your app actually does.
TL;DR
- Simple API or full-stack app, small team → a PaaS like Render or Railway. Git-push deploys, managed database, no servers to patch.
- You want cloud control and lower cost at scale → a VPS on DigitalOcean or Hetzner, with a process manager and a reverse proxy.
- Serverless / spiky traffic, stateless API → serverless functions (Vercel, Netlify, AWS Lambda) — but mind cold starts and the no-persistent-connections limitation.
- The trap: shared cPanel hosting that advertises "Node.js support." It technically runs Node but fights you on long-running processes, WebSockets, and build tooling. Avoid for anything real.
First, classify your app
The right host depends entirely on which of these you're building:
| App type | Needs | Best fit |
|---|---|---|
| Stateless REST/GraphQL API | A process that scales horizontally | PaaS or VPS |
| Real-time (WebSockets, chat, presence) | Long-lived connections, sticky sessions | VPS or PaaS (not serverless) |
| Background workers / queues | Always-on processes separate from web | PaaS with workers, or VPS |
| Spiky, stateless, bursty | Scale-to-zero, pay-per-invocation | Serverless functions |
Get this classification right and the host almost picks itself.
Option 1 — PaaS (Render, Railway): the default for most teams
Render and Railway are the modern home for a Node backend that needs a database and maybe a worker. You connect a repo, they build and run it, and you get a managed Postgres/Redis alongside without provisioning a VM.
- Render leans toward predictable production workloads — web services, background workers, cron jobs, and managed databases with a clear pricing structure.
- Railway optimizes for developer speed and a slick deploy experience; excellent for getting a full-stack app live fast.
Both handle persistent processes and WebSockets properly (unlike serverless), and both delete the entire category of server administration. For teams under ~10 engineers, this is usually the right call — engineer time costs more than the PaaS premium.
Option 2 — VPS (DigitalOcean, Hetzner): control and lower cost at scale
When you want to own the environment or cut per-unit cost, run Node on a VPS. The standard production setup:
- A Droplet (DigitalOcean) or cloud server (Hetzner) running a current LTS Node.
- A process manager — PM2 or a systemd service — to keep the app alive, restart on crash, and run across CPU cores in cluster mode.
- Nginx (or Caddy) as a reverse proxy in front, terminating TLS and serving static assets.
- A managed or self-hosted database, plus automated backups and monitoring.
DigitalOcean is the gentler path here — its tutorials cover this exact stack step by step, and its App Platform offers a halfway house if you want PaaS convenience on DO infrastructure. Hetzner is cheaper per unit if you're comfortable owning the whole stack. We compare the two in depth in DigitalOcean vs Hetzner.
The VPS route is more work — you own patching, TLS renewal, and recovery — but it's the cheapest at scale and gives you total control.
Option 3 — Serverless functions: only for the right shape
Vercel, Netlify, and AWS Lambda let you deploy Node as functions that scale to zero and bill per invocation. Genuinely great for spiky, stateless APIs and webhook handlers. But know the limits before you commit a whole backend:
- No persistent connections — WebSockets and long-lived DB pools don't fit the model (you need connection poolers or a different tier).
- Cold starts — the first request after idle can be slow.
- Execution time limits — long-running jobs get killed.
For a stateless API with uneven traffic, serverless is excellent and cheap. For a stateful real-time app, it's the wrong tool.
Our recommendation by scenario
- MVP or small product, want to move fast → Render or Railway with their managed Postgres.
- Real-time app (chat, collaboration, live data) → VPS on DigitalOcean (or Render web service) — never serverless.
- Cost-sensitive backend, infra owner on the team → Hetzner VPS with PM2 + Nginx.
- Webhook/event API with bursty, stateless traffic → serverless functions.
Whichever tier you choose, see the full framework in our hosting guide for developers. And if you're staffing the backend itself, our guide to hiring Node.js developers covers the vetting side.
FAQ
Can I host a Node.js app on shared cPanel hosting? Technically yes — many shared hosts expose a "Node.js app" feature via Passenger. In practice it fights you on long-running processes, WebSockets, and modern build tooling. Use a PaaS or VPS instead for anything beyond a toy.
Do I need PM2 if I use a PaaS? No. PaaS platforms manage process lifecycle, restarts, and scaling for you. PM2 (or systemd) is for the VPS route where you own process management.
Is serverless cheaper for Node? For low or spiky traffic, often yes — you pay per invocation and scale to zero. For steady high traffic or anything stateful, a always-on PaaS service or VPS is usually cheaper and simpler.
What Node version should production run? A current Active LTS release. Avoid odd-numbered (non-LTS) lines in production, and plan upgrades before your LTS line reaches end-of-life — see the Node.js release schedule.
Building a Node.js backend and unsure where to run it? Tell us your stack — we'll recommend the right tier, including how to deploy and monitor it.