What is the best Node.js hosting in 2026?
For an Express, NestJS or Fastify service, Render's free tier is the cheapest place to park one and $7/month buys the smallest paid instance; Fly.io keeps a small service online from roughly $2/month; Railway at $5/month plus usage is the fastest route to a working stack with a database beside it.
Granite — our own platform — is $9/month with $15 of usage credits, and fits when the API needs managed Postgres or Valkey, a background worker and a private registry in the same project, reached over internal DNS. If the service is one stateless endpoint with no database, the cheaper options above win and the table below says so.
Last updated 1 September 2026
Node hosting looks like a solved problem until the first deploy. Every platform in this comparison runs Node, most of them detect a package.json and build it without a Dockerfile, and all of them will serve an HTTP handler. The differences show up afterwards: whether the process is allowed to stay alive between requests, how many copies of it exist, and therefore how many database connections your pool is quietly holding open.
That last one catches people. A Node process with a pool of ten connections is one pool. The same service on a platform that runs three replicas is thirty connections, and a serverless deployment that starts a fresh instance per burst of traffic can exhaust a small Postgres entirely. Node's single-threaded event loop means you scale by adding processes, and every process you add multiplies everything it opens.
The other thing worth settling early is who builds the image. A buildpack that runs npm install on every deploy is the difference between a thirty-second and a four-minute release, and native modules — anything with a prebuilt binary per platform and libc — are where a build that works locally fails in CI.
How much does Node.js hosting cost?
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| Fly.io | ~$2 | Postgres (unmanaged app) | Dockerfile, buildpack | ||
| Railway | $5 | yes ($1 credits) | Git, Dockerfile, template | ||
| Render | $7 | yes (spins down) | Git, Dockerfile | ||
| Granite | $9 | from Advanced | Git, Docker image | ||
| Koyeb | $29 | limited | Serverless Postgres | Git, Dockerfile | |
| Google Cloud Run | usage-based | yes (monthly allowance) | via Cloud SQL | no (use GCS) | Container image |
Entry prices as published by each provider on 1 September 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
PaaS, serverless or a plain VPS?
A managed platform is where most production Node services end up, and for a reason: one long-lived process, a predictable monthly floor, a database somebody else backs up, and a connection pool that is opened once at boot rather than on every request.
Serverless — Cloud Run, Koyeb's scale-to-zero, and the function runtimes on Vercel and Netlify — fits Node better than it fits the JVM, because the runtime boots in a couple of hundred milliseconds. The catch is never the JavaScript. It is everything the instance opens on the way up: a pool, a Redis client, a warm cache. An API that is genuinely idle most of the day wins here. One that talks to Postgres on every request usually pays more, and answers slower, than a $7 always-on instance.
A plain VPS is cheaper per gigabyte and always will be, and with a process manager and a reverse proxy it will run Node happily for years. What you take on is TLS renewal, zero-downtime restarts, log rotation and being the person who is awake when the host reboots.
Steady traffic, and the service has a database, a queue or uploads behind it
Managed platform
One long-lived process, one pool, a predictable floor and nothing to operate.
Granite · Railway · Render
An API that is idle most of the day, and paying nothing while it waits matters most
Serverless
Scales to zero; put a pooler in front of Postgres before you rely on it.
Cloud Run · Koyeb
You would rather own the machine and price per gigabyte decides
Plain VPS
Cheapest per resource — you own TLS, restarts, logs and uptime.
Hetzner · DigitalOcean · anyone
What does each platform actually give you?
Fly.io
- Best for
- The cheapest way to keep a small Node service online, and the best option if latency to several regions matters.
- Pricing
- Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
- Cheapest entry point in this table; a 256 MB machine runs a modest Express or Fastify service fine.
- The process stays alive between requests, so the connection pool and any in-memory cache survive.
- Multi-region deployment and Anycast routing are first-class rather than add-ons.
- No free tier for new organisations since October 2024.
- Postgres is a Fly app you operate yourself, not a managed service with someone else on call.
- 256 MB is tight for a NestJS app with a large dependency graph — budget for 512 MB.
Railway
- Best for
- Getting a Node service and its database running in the same project in an afternoon.
- Pricing
- Billing is per second of actual usage against a monthly minimum: $5 on Hobby and $20 on Pro, each including that much usage credit. The free plan is a 30-day trial with $5 of credits and $1 a month afterwards, capped at 1 vCPU and 0.5 GB per service. Pro includes unlimited workspace seats.
- Detects a Node project and builds it without configuration; the template catalogue covers most stacks.
- Databases sit alongside services in one project, so the connection string is wired for you.
- A free plan and a trial, so you can evaluate without a card.
- Usage-based billing on top of the base fee makes the monthly cost hard to predict.
- Hobby is one developer per workspace, so any collaboration raises the floor from $5 to Pro's $20 a month.
Render
- Best for
- A free place to put an API someone else needs to call, and a simple paid tier once it matters.
- Pricing
- Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
- A real free tier for web services, which is now rare.
- 512 MB on the Starter tier is comfortable for most Node services.
- Straightforward model: pick an instance size, push to Git, done.
- Free services spin down after fifteen minutes idle, so the first request afterwards pays a cold start and reopens the pool.
- Costs climb quickly past one small instance.
Granite
- Best for
- Running a Node API together with the Postgres, Valkey, storage and registry it depends on, with no networking to configure.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- Managed Postgres, MySQL, MongoDB, Valkey, S3-compatible storage and a private Docker registry live in the same project and reach each other over internal DNS.
- Databases have no public endpoint, so the pool never opens a connection across the internet.
- Deploy a prebuilt image, or let Granite build from a GitHub, GitLab or Bitbucket push with no Dockerfile.
- Workers and cron jobs are their own resource type, so a queue consumer is not a second web service.
- No free tier — the cheapest way in is $9/month.
- Persistent volumes start on the Advanced plan, so Hobby suits stateless services only.
- Fewer regions than the hyperscalers, and no multi-region routing yet.
Koyeb
- Best for
- Edge deployment with scale-to-zero, if the entry price is acceptable.
- Pricing
- Pro is $29/month plus compute and includes $10 of it; Scale is $299/month including $100. Serverless Postgres has a free tier of 5 hours a month at 0.25 vCPU, 1 GB RAM and 1 GB of storage, after which the smallest always-on instance is $29.76/month plus $0.50 per GB stored.
- Scale-to-zero with a fast wake, and Node starts quickly enough for it to be usable.
- Edge locations included rather than sold separately.
- The highest entry price of any managed option here.
- Smaller ecosystem and community than Railway or Render.
Google Cloud Run
- Best for
- A JSON API that is idle most of the day, where paying nothing while waiting matters more than keeping state in memory.
- Pricing
- No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
- Scales to zero, so an idle service is genuinely free.
- Takes any container image, so your Dockerfile is the contract.
- Effectively unlimited scale ceiling if something takes off.
- Every cold start opens a fresh connection pool; a chatty service needs a pooler in front of Postgres.
- You assemble the rest yourself — Cloud SQL, secrets and networking are separate products.
- No persistent disk; state has to live in a bucket or a database.
What does a Node.js app need from a host?
- One pool per process, and how many processes
- Node is single-threaded, so you scale it by running more copies, and every copy opens its own connection pool. Multiply your pool size by the replica count before you size the database: ten connections across three replicas is thirty, and a small Postgres allows about a hundred in total.
- Does the process stay alive?
- An always-on instance opens its pool, its Redis client and its caches once at boot. A serverless instance does it on every cold start. That single difference decides both the latency of the first request after idle and how many connections your database sees under bursty traffic.
- Build caching and lockfiles
- A cold npm install on every deploy is minutes you pay for on every push. Check that the platform caches node_modules or the package manager store between builds, and that it installs from the lockfile — npm ci, pnpm install --frozen-lockfile — rather than resolving versions afresh.
- Native modules and the right binary
- Anything that ships a prebuilt binary per platform — sharp, bcrypt, better-sqlite3, the lightningcss and swc binaries a build tool pulls in — needs the install to run on the same architecture and libc as the runtime. An arm64 laptop and an amd64 Alpine builder are the usual cause of a module that cannot be found only in CI.
- SIGTERM and in-flight requests
- Rolling deploys send SIGTERM and then wait. Node does not stop the server for you: call server.close(), drain the pool, and exit. Without it every release kills whatever requests were open, and a queue consumer loses whatever job it was holding.
- Workers and cron as first-class processes
- A BullMQ consumer or a nightly job is not a web service and should not be deployed as one — it has no port to bind and no health check to answer. Check whether the platform models a worker and a scheduled job separately, or whether you will be faking one with a web service that ignores traffic.
$ docker images api
REPOSITORY TAG SIZE
api node-full 1.11GB
api alpine 182MB
api distroless 126MB
Where do background jobs and queue workers run?
Not in the request handler, and not behind a fire-and-forget promise that dies with the process. BullMQ is the common choice and wants Redis or Valkey; pg-boss keeps the queue in Postgres and saves you a second dependency; Agenda does the same against MongoDB. The consumer is its own entry point — node worker.js — built from the same image as the API so the job code and the request code can never disagree. On Granite that is a worker resource in the application, with the broker as a managed Valkey beside it. When a deploy or a crash takes the container away mid-job, BullMQ returns the job to the queue after its lock expires, so the handler has to tolerate being run a second time.
How do scheduled tasks and cron work?
node-cron inside the API process is the tempting version and the one that breaks: the timer lives in every replica, so two containers send the invoice email twice. BullMQ's repeatable jobs avoid that by putting the schedule in Redis, where only one worker claims each occurrence. A platform cron is the simplest fix of all — on Granite a cron-job resource runs node scripts/rebuild-index.js on a cron expression as a single container, with Forbid or Allow deciding what happens when a run overlaps the next slot. Read its output with novps resources logs <id> --since 1d, separately from the API logs.
Is Postgres managed, and what about backups?
Managed on Render, Railway, Koyeb and Granite; on Fly it is an app you operate; on Cloud Run it is Cloud SQL, billed and configured separately. Granite runs scheduled backups into external storage and support can perform point-in-time recovery for Postgres on request — the interval is not published, so ask rather than assume. Databases carry no public endpoint, so the app connects over internal DNS and you connect with novps port-forward database <id> -l 5432. Pooling deserves a thought before you scale: pg opens a pool per process, so ten connections per replica across four replicas is forty, and a small managed instance will refuse the forty-first.
How do deploys and migrations work?
Push to the tracked branch and the platform builds and rolls out the image, or push a tag and let it watch the registry. Migrations — prisma migrate deploy, knex migrate:latest, drizzle-kit migrate — need to run once per deploy, not once per replica: Render and Railway have a release command for it, and on Granite you run it from the resource's Console tab or over a forwarded database port before rolling the image. You do not need pm2 on any of these platforms; the supervisor is the platform, and its restart policy is better informed than a process manager inside your container. What you do need is a SIGTERM handler that stops the server and drains in-flight requests.
What does it actually cost per month?
An API, a queue consumer and a small Postgres, priced as of 1 September 2026. Fly.io is the cheapest arithmetic: two shared-cpu-1x machines at 256 MB are $2.02 each, which Node fits into far more comfortably than Python or Ruby, plus a Postgres you run yourself. Render is $7 plus $7 plus $6 for a 256 MB managed Postgres, so $20. Cloud Run bills $0.000018 per vCPU-second with 180,000 free each month, which suits the API and not the consumer, since a worker that scales to zero consumes nothing. Granite is $9 with $15 of credits across all three, and the 1 GiB per-service ceiling on Hobby is real headroom for Node.
So which should you pick?
A side project you want online for as little as possible. Render's free tier if you can live with a cold start after fifteen minutes idle, otherwise Fly.io at roughly $2/month for a machine that never sleeps.
An API that is idle most of the day. Cloud Run. Scaling to zero means you pay nothing while it waits, and Node boots quickly enough for the trade-off to be reasonable — put a connection pooler in front of Postgres before you depend on it.
A working stack in an afternoon. Railway. The Node build needs no configuration and a Postgres in the same project is two clicks, at the cost of a monthly bill that is harder to predict.
A real application, not just an endpoint. This is where we would argue for Granite: an Express or NestJS API, the managed Postgres or Valkey it queries, a BullMQ worker as its own resource, and a private registry for the image — in one project, addressing each other over internal DNS, with no database exposed to the internet. From $9/month with $15 of usage credits included.
Deploying a NestJS app and want the Dockerfile first? The NestJS Dockerfile walkthrough covers the multi-stage build these images come from.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.
Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.
Seven platforms for Django, Flask, FastAPI or a script with no HTTP port at all — and how to tell which of those you are actually deploying.
Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.
Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.
Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.
Seven platforms for a framework that renders on every request — weighed on streaming, adapters, and how far the loaders sit from the database.
Six platforms weighed on what the JVM actually asks for: memory it is allowed to use, a container that knows its own limits, and a start-up you can afford to repeat.
Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.
Five ways to serve HTML that is already written — and an honest note about which of them we are not the right answer for.