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 7 August 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 7 August 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
- Hobby is $5/month including $5 of usage credits; Pro is $20/month per workspace including $20 of credits. A free plan gives $1 of monthly credits, and there is a 30-day trial.
- 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.
- The Pro fee is per workspace, which adds up for a small team.
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
- The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.
- 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
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.
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.