The Best NestJS Hosting Platforms in 2026

NestJS is a framework with opinions, and one of them is that your application is a long-lived process. Dependency injection resolves a container at bootstrap. @nestjs/schedule registers cron jobs on a timer in that process. Gateways hold WebSocket connections. Microservice transports keep a message-broker consumer open. None of that is exotic — it's the default way people use the framework — and all of it assumes the process is still there in five minutes.

That single fact does most of the work in deciding where to host it. So: what NestJS actually needs, then the platforms, then which to pick.

What NestJS needs from a host

• A persistent process. Not a warm function that might be reused — an actual process you can rely on being alive between requests.
• A build step and a distinct start command. nest build produces dist/, and production runs node dist/main.js. Platforms that assume build output is static files will fight you.
• WebSocket support, if you use gateways. Plenty of platforms proxy HTTP happily and handle upgrades badly.
• Somewhere to run migrations. TypeORM and Prisma both want a step that isn't your start command.
• Enough memory to build. TypeScript compilation on a decent-sized Nest project will OOM in 512 MB and take a while in 1 GB.

The one that catches teams out is the cron. @nestjs/schedule is the natural way to write a scheduled task in Nest, and it's a timer inside your process. On a platform that scales to zero between requests, or spreads traffic across three instances, that timer either doesn't fire or fires three times. Neither failure is loud.

The options

Render

The default recommendation for a reason. Web services are long-running processes, build and start commands are separate first-class fields, WebSockets work, and there are managed Postgres and Redis next door. The Heroku-shaped experience without the Heroku-shaped bill.

Caveat: the cheapest tiers spin down on idle, and a cold start on a Nest app with a large DI graph is not instant. If you're on a free or hobby tier, budget for the first request after a quiet period being slow.

Railway

Excellent developer experience and the fastest path from repo to running service. Detection generally gets Nest right without configuration, and the service graph makes wiring a database to an API genuinely pleasant.

Caveat: the usage-based pricing is easy to like at small scale and easy to be surprised by at larger scale. Watch what an always-on service actually costs over a month before you assume.

Fly.io

Runs your app as Firecracker microVMs close to users, with real control over regions and networking. If you have a latency requirement or a multi-region story, this is the platform that takes it seriously.

Caveat: more infrastructure surface than the others. You're writing a fly.toml, thinking about volumes and regions, and doing more of your own operations. That's a feature if you want it and friction if you don't.

PandaStack

Ours: apps run inside Firecracker microVMs — a full Linux guest with its own kernel, not a container on a shared one. A Node app is auto-detected from the repo, runtime versions come from your .nvmrc or .tool-versions, and deploys are blue-green: the new version is built, health-checked, and only then does traffic flip.

The differentiator is what idle costs. An app sleeps after an idle window — 15 minutes by default, tunable down to 60 seconds — and releases CPU, RAM, and disk entirely. The next real request boots a fresh sandbox from the deploy-time artifact and answers it. You pay $0.054 per active vCPU-hour and $0.0162 per working-set GiB-hour, so a staging API nobody touched over the weekend costs roughly nothing — the meters follow what you actually use, not what you provisioned.

The build memory question is handled: the base runtime is 4 GiB, which exists specifically because TypeScript builds OOM'd at 2. Managed Postgres is on the same platform and the same bill.

Caveat: scale-to-zero means the first request after a sleep pays a boot. If your API must answer every request with no wake latency, turn auto-hibernate off — and then you're paying for an always-on service like anywhere else.

Heroku

Still works, still boring in the good sense, and the release-phase hook remains the cleanest built-in answer to 'run migrations before the new version takes traffic' that any of these platforms has.

Caveat: price per unit of compute is the highest here by a distance, and the platform's development has been unhurried. Most teams leaving Heroku are leaving over the bill.

AWS — ECS on Fargate or App Runner

If you're already on AWS and your Nest app needs to sit inside a VPC with an RDS instance and a security group, this is where it goes. App Runner is the low-configuration path; ECS on Fargate is the one you graduate to when you need control.

Caveat: the amount of surrounding infrastructure is the point and the problem. A load balancer, a task definition, a service, log groups, and an IAM role stand between you and a deployed API. Worth it inside a VPC-shaped organisation, heavy outside one.

Vercel and other serverless platforms

You can run Nest on serverless functions — there are adapters, and for a plain REST API with no gateways and no scheduler it works. It's genuinely a good fit when your Nest app is a stateless HTTP API sitting alongside a Next.js frontend.

Caveat, and it's the important one: WebSocket gateways don't work, @nestjs/schedule doesn't fire reliably, microservice transports have nowhere to live, and cold starts pay for the DI container bootstrap on every invocation that misses a warm instance. If you're using the parts of Nest that make Nest worth using, this is the wrong shape.

Deploying a Nest app, concretely

The configuration is nearly identical everywhere — build, then start the built output, and read the port from the environment:

// src/main.ts
import { NestFactory } from "@nestjs/core";
import { AppModule } from "./app.module";

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  // Bind 0.0.0.0, not localhost — a platform health check comes from outside
  await app.listen(process.env.PORT ?? 3000, "0.0.0.0");
}
bootstrap();

On PandaStack that's a committed manifest, or the same three fields set on the app:

{
  "type": "node",
  "installCommand": "npm ci",
  "buildCommand": "npm run build && npx prisma migrate deploy",
  "startCommand": "node dist/main.js"
}

pandastack app create \
  --name orders-api \
  --git-url https://github.com/me/orders-api \
  --env "NODE_ENV=production,PORT=3000"
pandastack app deploy <app-id> --follow

The scheduler decision

If you use @nestjs/schedule, you have three honest options and should pick one deliberately rather than discovering the problem later:

1. Run exactly one always-on instance and accept it as a single point of failure for scheduled work. Fine for most applications, and the simplest thing that works.
2. Take a distributed lock before each job runs, so only one of N instances proceeds. A Postgres advisory lock is enough; you don't need Redis for this.
3. Move scheduled work out of the app entirely, onto a platform cron that hits an authenticated endpoint or runs a separate one-off process. This is the only option that survives scale-to-zero, because something external is doing the waking.

Option three is also the one that lets you keep the cheap idle behaviour. An app that sleeps when nobody's using it, plus a scheduler that lives outside it, is a better shape than an always-on process kept alive purely so a timer fires.

Which one

• You want the least thinking and a Postgres next door → Render.
• You want the nicest developer experience getting started → Railway.
• You need multi-region or fine-grained network control → Fly.io.
• The service is idle most of the time and you don't want to pay for that → PandaStack.
• You're inside an AWS VPC with RDS → ECS on Fargate or App Runner.
• It's a stateless REST API next to a Next.js frontend, with no gateways or scheduler → serverless is fine, and Vercel is the easy call.

The general rule: if you're using NestJS the way NestJS wants to be used — DI, gateways, scheduler, microservices — host it as a long-running process. Every platform above except the serverless ones does that well, and choosing between them is mostly about what idle costs and how much infrastructure you want to own.