Node.js hosting 2026

Node is a long-lived process, not a per-request script. Unlike PHP, where the web server spins up the interpreter on each request, a Node app runs continuously and listens on a port itself. So you need a VPS where the process can stay alive: install the current LTS via nvm and a PM2 process manager (autostart, restart on crash, cluster across cores), with Nginx in front terminating SSL and proxying to your port.

Single thread and CPU load. Node's event loop is single-threaded: one heavy synchronous operation blocks everyone. So for CPU-heavy work you enable a PM2 cluster (one process per core) — hence the direct dependence on vCPU count. A typical API/SSR app is fine on 1–2 GB RAM, but building the frontend (Next.js, Vite) on the server temporarily eats noticeably more memory — leave headroom or build in CI.

Real-time and long connections. Node's strength is WebSocket, chats, notifications, streaming. These need a stable network and correctly proxied long connections through Nginx (proxy_read_timeout, upgrade headers). If you plan to scale real-time across several instances, you'll need Redis as a shared layer for sessions and pub/sub.

Deploy and database. Alongside the app you usually run PostgreSQL or MongoDB on the same VPS (or a managed DB separately). Deploy is git pull + npm ci + build + pm2 reload, or via CI. For a prototype it's faster to start on PaaS (see /hosting/paas — Railway/Render deploy Node from a repo in a couple of clicks); when you need predictable pricing and full environment control, move to a VPS. Shared for Node is a rare exception.