"Best Node.js hosting" has one fork that decides almost everything, and most lists skip it: does your app need a long-running process, or not? A stateless API that answers a request and forgets it is a completely different hosting problem from a server that holds websockets, runs cron in-process, and keeps state in memory. Answer that first and the shortlist writes itself.
The fork: is it a server or a set of functions?
- Serverless-friendly — stateless request handlers, a REST/GraphQL API over a database, scheduled tasks that can run as isolated invocations. No in-memory state between requests.
- Needs a real server — websockets/SSE, long-running jobs or queues in-process, cron that shares memory with the app, or anything that keeps a connection open. Serverless will fight you here.
Your answer maps straight to the table below.
The options, sorted by fit
| Host | Runtime | Best for | Free tier | Main watch-out |
|---|---|---|---|---|
| Railway | Full Node runtime; deploys from a repo/Dockerfile | Full-stack apps with a DB, websockets, cron, workers | Trial credit | Priced closer to a running instance; you own caching/CDN |
| Render | Full Node runtime; web service + background workers + cron | Predictable flat-rate long-running services | Yes (spin-down) | Free tier spins down — cold starts on low traffic |
| Fly.io | Node in a container, deployed multi-region | Latency-sensitive APIs; run close to users | Trial | You manage machines/regions — more ops surface |
| Vercel / Netlify | Serverless functions (not a long-running server) | Stateless APIs, cron-lite, Jamstack backends | Yes | No always-on process: websockets, long jobs, and in-memory state don't fit |
| Cloudflare Workers | Edge runtime (V8 isolates), not full Node | Global low-latency APIs, high request volume | Yes (generous) | Not 100% Node-compatible; some npm packages/APIs won't run |
| Heroku | Classic Node PaaS (dynos) | Teams that want the original git-push PaaS DX | No (paid dynos) | Pricier per resource than newer PaaS; dyno sleep on low tiers |
| Self-host (VPS/Docker) | Full control via a process manager + reverse proxy | Cheapest at scale; full OS access | N/A | You own uptime, TLS, scaling, and monitoring |
Three recommendations
A long-running full-stack app (DB, websockets, jobs)
Reach for Railway or Render. Both run your Node process as a real server, sit next to a managed database, and handle background workers and cron as first-class services. Railway's DX is fast and repo-driven; Render's flat pricing is easy to forecast. Pick Fly.io instead when you need the app to run in multiple regions close to users.
A stateless API or Jamstack backend
Serverless functions on Vercel or Netlify scale to zero and to spikes without you managing a server — ideal when there's no long-lived connection or in-memory state. For very high request volume or global latency, Cloudflare Workers is cheaper still, provided your dependencies run on its edge runtime.
Cost-at-scale or full control
A self-hosted Node process behind a reverse proxy on a VPS is the cheapest option once traffic is steady and predictable — you trade managed convenience for owning uptime, TLS, and scaling yourself.
The trap to avoid
The classic mistake is shipping a websocket or background-job app to a serverless platform because it had the best free tier, then discovering functions time out, can't hold a connection, and lose in-memory state between invocations. The inverse — paying for an always-on server to run a handful of stateless endpoints — wastes money. Match the runtime to the workload and neither happens.
How to choose in 60 seconds
- Websockets, cron-in-process, or in-memory state? A real server: Railway or Render; Fly.io for multi-region.
- Stateless request/response only? Serverless: Vercel or Netlify; Cloudflare Workers for scale, if your deps run on the edge.
- Steady, high, predictable traffic and you want the lowest bill? Self-host on a VPS.
- Unsure? Start on a real-server free/trial tier — it runs everything, and you can optimize toward serverless later if the workload turns out to be stateless.
A note on pricing
Prices and free-tier limits change often — verify current numbers on each provider's pricing page. The stable signal is the model's shape: serverless bills by invocation and duration (great at low or spiky traffic, watch it at sustained high volume), while a running instance bills whether or not it's busy (cheaper under steady load). That shape predicts your bill better than any headline number.
FAQ
Do I need a server, or can I use serverless functions?
If your Node app is a set of stateless request/response handlers, serverless (Vercel, Netlify, Cloudflare Workers) is cheaper and scales itself. If it holds websockets, runs background jobs or cron in-process, or keeps in-memory state, you need a long-running server — Railway, Render, or Fly.
Will Cloudflare Workers run any Node app?
Not quite. Workers run on a V8 edge runtime with a growing but incomplete Node compatibility layer. Simple APIs run great; apps that depend on native modules or less-common Node APIs may not port without changes.
Is Heroku still a reasonable choice?
Yes for the DX, but newer PaaS options (Railway, Render) usually give more resource per dollar and a smoother free/trial path. Heroku still shines if your team already knows it and values its maturity.
Building the app these run, not just choosing where to put it? The MVP Machine turns a spec into a shipped product.