The best Node.js hosting platforms in 2026

Node hosting looks like a solved problem until you try to host something that isn't a request-in, response-out API. Then you find out that half the platforms in the category are not really hosting a Node process at all — they are hosting a function that happens to be written in JavaScript, and the difference shows up the first time you open a WebSocket, start a queue worker, or write a response that takes ninety seconds to finish.

I'm Ajay, I build PandaStack, which is one of the options below. This is the comparison I wish I'd had: sorted by what your app actually needs to do, with the failure modes named.

Ask one question first

Does your process need to stay alive between requests? Everything else follows from the answer.

• No — every request is independent, finishes in a few seconds, and holds nothing in memory. Serverless platforms are excellent for this and you should probably use one.
• Yes — you have WebSockets, server-sent events, an in-process job queue, a long-lived database pool, a cache you actually rely on, a cron loop, or a request that can legitimately run for minutes. You want a machine, not a function.

People pick a serverless platform for a category-two app all the time, because the deploy story is so good, and then spend a quarter working around it — an external queue for the jobs, a hosted pub/sub for the sockets, a separate scheduler for the cron. That's a real architecture, but you should choose it deliberately rather than inherit it from a hosting decision.

The platforms

Vercel

Unbeatable if the Node in question is a Next.js app. The integration is genuinely deep — routing, caching, image handling, preview deployments — and nothing else in the list matches it for that specific case. For a plain Express or Fastify server it's a worse fit: you're deploying into a function runtime, with the execution-duration ceiling and the no-persistent-connection constraint that implies. Fluid compute has softened the cold-start story considerably, but it hasn't turned the platform into a long-running-process host.

Render and Railway

The default recommendation for a plain Node server, and deservedly so. You get a real long-running process, a managed Postgres next to it, background workers as a first-class object, and a deploy flow that's a git push. Railway's pricing is usage-based and Render's is instance-based, which matters more than the sticker rate: pick based on whether your traffic is spiky or steady. The main complaint from both camps at scale is cost creep once you're running several always-on services that are mostly idle.

Fly.io

The right answer when geography is part of the problem — you want the process near the user, or near a database replica, and you're willing to think about regions. Machines are real VMs, so anything a Node process can do works. The trade is that you're now operating something: Fly gives you more control than a PaaS and expects more from you in return.

Google Cloud Run

A container that scales to zero, with generous request timeouts and no artificial limits on what the process may do. Excellent, boring infrastructure. The friction is that you're writing a Dockerfile and living in GCP's IAM model, which is a real tax if you're a small team who just wanted to deploy an API.

AWS (Lambda, App Runner, ECS Fargate)

Lambda for genuinely event-driven work, App Runner if you want a container without operating a cluster, Fargate when you've outgrown both. All three are fine. All three cost you more setup than anything else on this list, and the reason to choose them is usually that the rest of your infrastructure is already there.

PandaStack (mine)

Your app runs as a normal Node process inside its own Firecracker microVM, built straight from the repo — no Dockerfile. Because it's a VM and not a function, WebSockets, workers, in-process schedulers and long requests all just work. Two things are specific to this design: the app can sleep when idle and wake on the next request, so an app nobody is using bills almost nothing; and each deploy is blue-green, with the old VM kept until the new one passes its health check. Runtime version comes from your repo — a `.nvmrc` or `.tool-versions` file is honoured rather than a dropdown in a dashboard.

# Deploy a plain Node/Express repo — no Dockerfile, no build config
pandastack app create \
  --name api \
  --git-url https://github.com/acme/api \
  --git-branch main \
  --port 3000

# Subsequent deploys are a git push, or an explicit one:
pandastack app deploy <app-id> --follow

Where it's the wrong answer: if you're a Next.js shop who wants ISR and edge middleware behaving exactly as documented, use Vercel. If you need a global anycast footprint, use something built for that. And a VM boots in about 179ms from snapshot but a cold app wake is measured in seconds, not milliseconds, because the app process itself has to start — if you need single-digit-millisecond wake on an idle app, this is not it.

The five things worth checking before you commit

1. Maximum request duration. Find your slowest real endpoint — the report export, the PDF render — and check it fits with room to spare.
2. WebSocket and SSE support, stated explicitly. 'Supports HTTP/2' is not an answer to this question.
3. How Node version is chosen. A platform that reads `.nvmrc` or `package.json` engines from the repo will not drift from local. A dropdown in a dashboard will.
4. What happens to a build that runs out of memory. Next.js and TypeScript builds are memory-hungry, and a build box smaller than your laptop is the single most common cause of 'it builds locally'.
5. Zero-downtime deploys, by name. Blue-green or rolling — either is fine. 'We restart the process' is not.

Short version

Next.js: Vercel. A conventional API with a database and a couple of workers: Render or Railway. Geography matters: Fly. Already deep in a cloud: Cloud Run or App Runner. Long-lived connections, background work in-process, and an idle bill you don't want to pay: a microVM platform like PandaStack. Nothing here is a trick answer — the mistake is picking a function runtime for an app that needed a process.