NestJS is a structured, TypeScript-first Node.js framework that produces long-running server applications — not serverless functions in the typical case. A production Nest app usually wants: a persistent process, a relational database (TypeORM/Prisma), often Redis for caching/queues (BullMQ), WebSocket support, and a place to run background workers and migrations. The best hosting is whatever serves those needs with the least friction. Here's a fair 2026 guide.
What NestJS hosting actually needs
Before comparing platforms, list the real requirements:
- A long-lived Node process (not a per-request function), ideally with graceful shutdown for rolling deploys.
- A managed database — Postgres or MySQL via Prisma/TypeORM.
- Redis for caching and BullMQ queues (common in Nest apps).
- A way to run migrations as a deploy step or job.
- Background workers — Nest apps frequently split HTTP and worker processes.
- WebSockets (Nest Gateways) if you use real-time features.
- Env-var configuration and secrets.
A clean Nest build
Nest builds to plain JS. A typical production Dockerfile:
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/main.js"]Add a health endpoint with @nestjs/terminus and you're production-shaped:
@Get('health')
@HealthCheck()
check() {
return this.health.check([() => this.db.pingCheck('database')]);
}Hosting options at a glance
| Platform | Long-running server | Managed DB | Redis | Background workers |
|---|---|---|---|---|
| PandaStack | Yes (containers) | Yes (PG/MySQL/Mongo/Redis) | Yes (managed) | Yes (extra services/cronjobs) |
| Render | Yes | Yes (PG) | Yes (key-value) | Yes (workers) |
| Railway | Yes | Yes | Yes | Yes |
| Fly.io | Yes (Machines) | Managed PG | Via Upstash/own | Yes |
| AWS (ECS/Fargate) | Yes | RDS (separate) | ElastiCache | Yes |
PandaStack
For a Nest app that wants its database and Redis wired in without juggling providers, PandaStack fits the shape well. Connect the Git repo: it auto-detects Node or uses your Dockerfile, builds with rootless BuildKit in an ephemeral Kubernetes Job, and deploys via Helm. Provision a managed PostgreSQL or MySQL and DATABASE_URL is injected — exactly what Prisma/TypeORM expect.
Why it suits Nest:
- Managed Postgres/MySQL + Redis all on one platform (Redis via KubeBlocks), so BullMQ and your ORM both have what they need.
- Cronjobs for scheduled tasks, and you can run a separate worker service for BullMQ consumers.
- Migrations as a step: run
prisma migrate deployor TypeORM migrations against the injectedDATABASE_URL. - Live logs and metrics built in (Elasticsearch logs, ClickHouse metrics) — useful for a structured Nest app.
- Free tier to start: 5 web services covers an HTTP server + a worker, plus a managed DB.
Honest caveats: WebSocket-heavy apps and always-on workers should run on a paid compute tier, not the scale-to-zero free tier (cold-starts and idling break persistent connections and queue consumers). Free-tier DBs are dev/hobby-sized; PandaStack is newer with a growing ecosystem.
Render
Render is a mature, comfortable home for Nest: web services for the API, background workers for BullMQ, managed Postgres, a managed key-value (Redis-compatible) offering, and cron jobs. Per-instance pricing is predictable. A strong, proven choice, especially if you value maturity.
Railway
Railway makes spinning up a Nest API alongside Postgres and Redis very fast, with great DX and templates. Usage-based pricing suits variable load. Excellent for getting a Nest stack running quickly; watch metered costs at scale.
Fly.io
Fly.io runs Nest as a Machine with per-second billing and edge placement, with a managed Postgres option and Redis via partners. Good when you need low latency in specific regions or fine control; expect more hands-on configuration.
AWS (ECS/Fargate)
If you're committed to AWS, run Nest on ECS/Fargate with RDS and ElastiCache. Maximum integration and control, maximum plumbing (load balancers, task definitions, IAM, VPC). Right for AWS-bound teams with platform expertise; heavy for a small team that just wants the API up.
Recommendations by situation
- Want DB + Redis + cron in one git-push workflow → PandaStack.
- Want a mature managed PaaS with workers → Render.
- Want fastest setup + great DX → Railway.
- Need edge regions / fine control → Fly.io.
- Committed to AWS → ECS/Fargate.
The practical advice: a typical Nest production setup is an API service, a worker service, Postgres, and Redis. Platforms that bundle all four (PandaStack, Render, Railway) save you from stitching providers together — which matters most when you're moving fast.
References
- NestJS docs: https://docs.nestjs.com/
- NestJS deployment guide: https://docs.nestjs.com/deployment
- Prisma deploy/migrate: https://www.prisma.io/docs/orm/prisma-migrate
- BullMQ: https://docs.bullmq.io/
- @nestjs/terminus health checks: https://docs.nestjs.com/recipes/terminus
---
Running Nest with Postgres and Redis? PandaStack auto-wires a managed database via DATABASE_URL, runs your API and BullMQ worker as separate services, and includes cronjobs — free to start at https://dashboard.pandastack.io.