NestJS hosting: deploy a NestJS API to the cloud (step-by-step, 2026)

Why NestJS deploys cleanly

NestJS gives Node.js back ends structure: modules, dependency injection, guards, pipes and a clear way to build REST, GraphQL and WebSocket APIs. In production it is simply a compiled Node.js app — TypeScript built into dist/, started with node. That makes it easy to host anywhere Node.js runs, including managed cloud hosting where you do not run the server yourself.

Production checklist before deploying

A few changes save hours later. Listen on the port the platform assigns. Read configuration through @nestjs/config from environment variables. Turn off TypeORM's synchronize in production and run migrations instead. Enable CORS only for your own frontends. Add a simple health route — GET /health returning 200 — so deploy checks and monitors have something to call.

• await app.listen(process.env.PORT ?? 3000)
• ConfigModule.forRoot() with environment variables
• TypeORM synchronize: false in production; run migrations
• app.enableCors({ origin: [your frontend URL] })
• A /health route that returns 200

Step 1 — Create the Node.js app

Order a Node.js plan in Create an app. A NestJS API with a database fits Starter (256 MB RAM, ₹2,388 a year); an API plus a frontend fits Growth (2 apps, 512 MB); several services or heavy traffic fit Business (1 GB) or Pro (2 GB). Choose Node.js 20 or newer. Using an api subdomain such as api.yourdomain.com keeps the API separate from your website.

Step 2 — NestJS preset and configuration

On App settings choose the NestJS preset: npm ci, npm run build, node dist/main.js. If your project uses a monorepo layout, adjust the start path to the right dist folder, or set the application root to the sub-folder. Paste your .env into environment variables — DATABASE_URL, JWT_SECRET and the rest. Values are stored privately and only names are shown back.

Step 3 — Database: PostgreSQL, MySQL or MongoDB

Create a PostgreSQL or MySQL/MariaDB database on the Databases page; it runs on the same server, so connect to localhost. TypeORM, Prisma, MikroORM and Sequelize all work. For MongoDB with Mongoose, use MongoDB Atlas: add 151.185.41.197/32 under Network Access and store the connection string as an environment variable. Run migrations as part of the build, or from the terminal, before the new release starts.

Step 4 — Deploy from GitHub

Connect GitHub, GitLab or Bitbucket on the Git page. Each push builds a new release in its own folder, starts it, and calls the app to confirm it answers. If the build or the health check fails, the previous release stays live and you get the full log by email. Release history keeps the last few builds for one-click rollback.

Step 5 — WebSockets, CORS and the domain

NestJS gateways with Socket.IO or ws work over HTTPS on your domain — the web server passes the upgrade through. Point the A record for your API subdomain to the server IP on the Domains page; free SSL issues automatically. Check CORS from your frontend's real origin, then watch Logs during the first requests.

What you get with Cloud Ninza NestJS hosting

A production home for NestJS without running servers:

• NestJS preset: build and start commands filled in
• Node.js 18–26; apps run continuously and restart on crash
• PostgreSQL and MySQL/MariaDB on the server; MongoDB Atlas by connection string
• Git deploys with health checks and automatic rollback
• Environment variables, live build output, logs and restarts
• WebSockets and GraphQL subscriptions over HTTPS
• Free SSL for api subdomains, issued automatically
• Servers in India, isolated accounts, yearly pricing from ₹2,388

Scaling up later

Start on a hosting plan and grow in place: a bigger plan adds memory and apps without moving. When you need several replicas behind a load balancer, background workers with Redis queues, or containers, move the API to a cloud server or managed Kubernetes — the same code, the same environment variables, new infrastructure.

Prisma, TypeORM or Mongoose in production

Each ORM has one production habit worth knowing. Prisma: run prisma generate as part of the build and prisma migrate deploy before the new release starts; the client is compiled for the server's platform automatically because the build runs on the server. TypeORM: keep synchronize off and run migrations from the compiled data source with the TypeORM CLI. Mongoose: set the connection string in an environment variable and let the driver handle reconnection; make sure the server IP is allowed in MongoDB Atlas.

Whichever you use, keep the database connection pool modest on a hosting plan — ten connections is plenty for most APIs — so a burst of traffic does not exhaust the database's connection limit.

Logging, validation and security defaults

NestJS makes good defaults easy. Use the global ValidationPipe with whitelist: true so unexpected fields are stripped from requests. Add helmet for security headers and a rate limiter on authentication routes. Log through Nest's logger to the console — the platform captures it, and Logs shows it with the rest of your app's output. Keep JWT secrets and API keys in environment variables, and rotate them by changing the variable and restarting the app.

Microservices on one plan

NestJS makes it tempting to split an app into many services early. On a hosting plan each service is an app sharing the account's memory, so two or three services fit comfortably on Growth or Business. Talk between them over HTTP on their own subdomains, or through an external message broker. Keep the split coarse until you have a reason: one well-structured NestJS app with modules is easier to run than five tiny services.

Monitoring a NestJS API after launch

Once the API is live, three signals tell you almost everything. Error rate: watch Logs after each deploy and after traffic spikes — an exception repeated on every request is a configuration problem, a rare one is a bug. Response time: log the duration of slow requests with an interceptor, and look at the database first when they grow. Memory: a steady climb that only falls on restart is a leak worth fixing before you buy a bigger plan.

Add an external uptime monitor that calls your /health route every minute, so you hear about a problem before your customers do. Pair it with the deploy emails from Git deployments — a failed health check after a push already tells you, and the previous release has stayed live while you look.

Finally, keep a short runbook in your repository: how to roll back, how to rotate secrets, and how to run migrations by hand. When something does go wrong late at night, a page of steps beats memory every time.

Key takeaways

The short version, for anyone skimming:

• NestJS in production is node dist/main.js listening on process.env.PORT.
• Configuration in environment variables; migrations instead of synchronize.
• PostgreSQL or MySQL on the server, or MongoDB Atlas after allowing the IP.
• Git deploys with health checks and automatic rollback.
• Cloud Ninza Node.js hosting for NestJS starts at ₹2,388 a year.