The best Fastify hosting platforms in 2026

Fastify gets chosen for one reason more than any other: it is a plain Node HTTP server that happens to be fast, with schema validation and a plugin system that does not fight you. That makes it a fine default for an API. It also means the deployment question is not 'where do I host Fastify' — it is 'where do I host a long-running Node process', and most hosting comparison pages answer a different question entirely, because they were written with Next.js in mind.

I'm Ajay, and I build PandaStack, so treat this as a vendor's roundup and weight it accordingly. The numbers I give for PandaStack are mine and I'll be specific about them. Everyone else is described qualitatively from public documentation, because pricing pages change faster than blog posts and a half-remembered figure is worse than no figure.

The thing that actually decides this

Fastify's runtime shape rules out or complicates several popular options before you get to features:

• It is one process that listens. Anything that wants to wrap each request in a fresh function invocation is working against the grain, and you lose the plugin lifecycle, the connection pool and the in-process cache that made Fastify worth choosing.
• It holds state between requests. A Postgres pool, a Redis client, a warm JIT. Serverless adapters re-establish some of that per cold start and the p99 shows it.
• It often has WebSockets or SSE. @fastify/websocket needs a connection that lives for minutes or hours. Function platforms with request-duration caps cannot host that at all.
• It is usually not the whole product. There's a worker, a cron job, a database. Whether the platform hosts those too is more important than its Node benchmark.

So the real axes are: does a process get to stay alive, what does it cost when nobody is calling it, and how long does the first request take after a quiet period.

1. Render

The most boring-in-a-good-way option. A Fastify app is a Web Service, you point it at a repo, it runs your start command and gives you a URL with TLS. Background workers, cron jobs and managed Postgres are first-class in the same product, which matters because your API is rarely deployed alone.

The tradeoff is instance-shaped continuous billing. An idle staging environment costs the same as a busy one. That is a perfectly good trade for production and a bad one for the eleven preview environments nobody has opened since spring.

2. Railway

Better ergonomics than Render for the first hour, and usage-based billing rather than fixed instances, which suits spiky APIs. Nixpacks detects Node without configuration. The database and service graph in one project is genuinely pleasant to work in.

It is opinionated in ways you will eventually meet — build customisation past a point means fighting the builder, and the pricing model rewards understanding it rather than ignoring it.

3. Fly.io

The right answer when latency to users in several regions is a real requirement rather than an aspiration. Fly runs your app as microVMs close to users, and Fastify with a read replica per region is a shape Fly is genuinely built for.

You are closer to the metal than on a PaaS. Volumes, regions and networking are yours to think about. Machines can auto-stop, which helps idle cost, but the mental model is more operator than developer.

4. Google Cloud Run

Containers, request-driven autoscaling including down to zero, and a generous free tier. Cloud Run has supported longer-lived requests and WebSockets for a while now, so the historical objection is weaker than it used to be.

You bring a container image, so you own a Dockerfile and a registry, and you are inside GCP's IAM model. For a team already on Google Cloud that is an advantage; for a three-person team shipping an API it is a lot of surface area.

5. AWS Lambda with an adapter

Included because people ask, not because I recommend it for this. @fastify/aws-lambda works and is well maintained. If your API is genuinely request/response, low traffic and already inside an AWS account, it is defensible and can be very cheap.

But you are paying Fastify's architecture cost without collecting its benefit. No WebSockets on the same path, cold starts on a runtime that wanted to stay warm, and a connection-pooling problem that needs RDS Proxy or equivalent to solve properly.

6. Heroku

Still the clearest mental model in the category, and for a small Fastify API it works on the first try. Add-ons cover Postgres and Redis without a decision.

Dyno pricing is per-dyno-hour and does not scale to zero on paid tiers, so the idle-cost problem is the same as Render's, with less modern tooling around it.

7. A VPS with Kamal or Dokku

Genuinely the cheapest cash option for a Fastify API, and it deserves to be on the list rather than dismissed. One machine, a git hook or a deploy command, systemd or Docker keeping the process up.

The cost is your attention: certificates, patches, backups, and being the person who notices when it stops. That is small on one server and stops being small the moment someone needs to be reachable at 2am.

8. PandaStack

My own, so read it sceptically. A Fastify app deploys from a git repo with no Dockerfile: the base image ships mise with Node 24 pre-warmed, framework detection classifies a repo with a package.json and no front-end framework as a plain Node app, and the start command comes from your package.json's start script.

{
  "name": "my-api",
  "type": "module",
  "scripts": {
    "start": "node src/server.js"
  },
  "dependencies": { "fastify": "^5.0.0" }
}

The one thing you must get right is the bind address. Fastify defaults to localhost, and a health check from outside the VM will never see it:

import Fastify from "fastify";

const app = Fastify({ logger: true });

app.get("/healthz", async () => ({ ok: true }));

// PORT and HOST are exported into the environment before your start command.
await app.listen({
  port: Number(process.env.PORT ?? 3000),
  host: process.env.HOST ?? "0.0.0.0",
});

The difference that matters here is what happens when nobody is calling the API. Each app is a Firecracker microVM that can scale to zero, and billing is one rate card — $0.054 per active vCPU-hour and $0.0162 per working-set GiB-hour, metered per second. An idle API bills close to nothing and a sleeping one bills nothing at all, which is why preview and staging environments stop being the thing that dominates the invoice.

The honest limitations: it is a smaller company than the rest of this list, and the app router in front of your VM is an HTTP reverse proxy, so raw TCP protocols do not cross it. WebSockets and SSE do, because they are HTTP upgrades. A raw TCP service on a public port does not.

How to actually pick

1. Count your non-production environments. If the answer is more than three, idle cost is your dominant variable and you should compare scale-to-zero options first.
2. Check whether you need WebSockets or SSE. If yes, cross off anything with a request-duration cap before you compare anything else.
3. Decide whether you want to own a Dockerfile. That single answer splits this list roughly in half.
4. Deploy the real repo to your top two. Every platform demos well; the difference shows up on the build that has a native dependency in it.

Fastify is a deliberately unexciting runtime shape, which is a compliment. The platforms that suit it are the ones that let a process be a process, and then charge you honestly for the hours it spends doing nothing.