Best Node.js Hosting in 2026: PaaS, Serverless and Edge Options Compared

Where you host a Node.js app depends on what kind of app it is. A long-running API or WebSocket server needs a platform that keeps a process alive; a request-driven API can run as serverless functions; a static front end needs neither. This guide groups the main options by that difference, with pricing and free-tier limits taken from each provider’s own pages in October 2026.

I have not benchmarked these platforms against each other, so there are no ratings here. The 2024 version of this post had several entries that no longer work for Node.js apps: Heroku’s free plan ended in 2022, Glitch ended project hosting on July 8, 2025, GitHub Pages and Surge only serve static files, and Deta’s site did not load when I checked. Those are removed or corrected below.

First, Pick the Hosting Model

Platforms That Run a Long-Lived Node.js Server

Render

Render deploys web services from Git or a Docker image. Its free web services are meant for testing: Render’s docs say a free service spins down after 15 minutes without traffic and takes about a minute to spin up again, each workspace gets 750 free instance hours a month, and Render says not to use free instances for production. Paid instances stay on and can use persistent disks.

Railway

Railway bills per second for CPU and memory. Its pricing page lists a free trial with $5 of credit for 30 days, a Free plan with $1 of monthly usage credit, and the Hobby plan at $5 a month including $5 of usage. It is quick to set up and also hosts databases next to your app.

Fly.io

Fly.io runs your app as lightweight virtual machines in regions you choose, billed by the second while they run. The smallest shared-CPU machine with 256 MB of memory was listed at $0.0030 an hour (about $2.19 a month in Ashburn), and there is no fixed plan to buy up front. A good fit when you want to run close to users in several regions.

Heroku

Heroku is the original Git-push platform and is still easy to use, but it no longer has a free plan. Eco dynos cost $5 a month and sleep after 30 minutes of inactivity; Basic dynos at $7 a month are always on.

DigitalOcean App Platform

DigitalOcean App Platform offers free hosting for up to three static sites, and Node.js services in containers from $5 a month for a shared 1 vCPU, 512 MiB instance.

Serverless and Edge Platforms

Vercel

Vercel is built around front-end frameworks such as Next.js, with Node.js code running as Vercel Functions. The Hobby plan is free but limited to personal, non-commercial use; Pro is $20 a month with usage-based billing beyond included credit. Use it when your Node.js code is request-driven and lives alongside a front end.

Netlify

Netlify works on credits: the free plan includes 300 credits a month, Personal is $9 a month and Pro $20. Node.js runs as Netlify Functions, which suit APIs and form handlers next to a static site.

Cloudflare Workers

Cloudflare Workers runs code at Cloudflare’s edge. The free plan includes 100,000 requests a day with 10 ms of CPU time per request; the paid plan starts at $5 a month. Workers support a subset of Node.js APIs, and modules such as child_process and worker_threads are not fully available, so it is not a drop-in home for a traditional Express server.

Containers on the Big Clouds

If your organization already uses a major cloud, run your container there: Google Cloud Run (containers that scale to zero), AWS (App Runner, or ECS on Fargate), or Azure Container Apps. They have free tiers or credits, but pricing is usage-based and detailed, so use each provider’s calculator rather than a blog post’s numbers. For a full AWS example, see deploying a container to AWS Lambda.

Quick Comparison

Prices change often; check the linked pages before you decide.

Make Your App Deploy-Ready Anywhere

Whichever platform you choose, the same few habits make deployment smooth. This small server shows them:

import http from 'node:http';

// Platforms tell your app which port to use; never hard-code it.
const PORT = Number(process.env.PORT ?? 3000);
let shuttingDown = false;

const server = http.createServer(async (req, res) => {
  if (req.url === '/healthz') {
    // Health checks let the platform route traffic only to healthy instances.
    res.writeHead(shuttingDown ? 503 : 200, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({ ok: !shuttingDown }));
  }
  if (req.url === '/slow') await new Promise(r => setTimeout(r, 1500)); // simulates real work
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello from Node.js\n');
});

server.listen(PORT, '0.0.0.0', () => console.log(`Listening on ${PORT}`));

// Platforms send SIGTERM before stopping or replacing an instance (deploys, scaling, restarts).
// Stop accepting connections, finish in-flight requests, then exit.
process.on('SIGTERM', () => {
  shuttingDown = true;
  console.log('SIGTERM received, draining connections');
  server.close(() => {
    console.log('All requests finished, exiting');
    process.exit(0);
  });
  server.closeIdleConnections();
  setTimeout(() => process.exit(1), 10_000).unref(); // hard stop if something hangs
});

• Read the port from PORT. Platforms assign it.
• Listen on 0.0.0.0 so the platform’s router can reach the process inside its container.
• Expose a health check such as /healthz so the platform only sends traffic to healthy instances.
• Shut down gracefully on SIGTERM. Platforms send it before replacing an instance during deploys and scaling.

I tested the shutdown path locally: with a 1.5-second request in flight, sending SIGTERM stopped new connections, let the slow request finish with status 200, and then exited cleanly.

$ PORT=4180 node server.js &
$ curl localhost:4180/slow &   # in flight
$ kill -TERM <pid>
SIGTERM received, draining connections
Hello from Node.js            # the slow request still completes
All requests finished, exiting

For container-based platforms, a minimal Dockerfile that runs as a non-root user:

FROM node:24-slim
ENV NODE_ENV=production
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

The Dockerfile passed hadolint with one informational note about using a named user; I did not build the image here because Docker was not installed. Pin the Node.js major version in package.json engines and in the base image so every platform runs the same runtime. For automated deploys, see building a CI/CD pipeline with Docker.

How to Choose

1. Hobby project or demo: Render’s free tier (accept the spin-down) or Railway’s trial.
2. Small production API: an always-on instance on Render, Railway, Fly.io, Heroku Basic or DigitalOcean.
3. Front end with some API routes: Vercel or Netlify Functions.
4. Global, latency-sensitive request handling: Cloudflare Workers or Fly.io regions, if your code fits their limits.
5. Company already on a big cloud: its container service.

Conclusion

Start from the shape of your app: long-running servers need a PaaS, containers or a VPS; request-driven code fits serverless; edge runtimes suit small, fast handlers. Free tiers are for experiments, and most sleep or cap usage. Build your app to read PORT, report health and shut down gracefully, and moving between platforms becomes easy. For the wider toolchain, see DevOps tools for each stage.

FAQs