Keep the NestJS build you already use
Use the committed package graph and Nest build output rather than a development watcher. Modules, providers, migrations, and configuration remain reviewable in Git.
Apps and APIs · plans from $10/month
Deploy NestJS.Compile TypeScript. Run the release artifact.
Build a NestJS application from source, start the emitted production entrypoint, verify dependency readiness, and keep deployment evidence beside the project.
Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy
Candidate release
NestJS
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
NestJSTypeScriptNode.js 24RESTQueuesWebSockets
The production path
A working NestJS project still needs a safe release.
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Promote the version that reports healthy
Start dist/main.js or the project's emitted entrypoint, bind globally to the manifest port, and promote only after the health controller responds.
Trace production back to source
Build output, runtime logs, health state, secrets, domains, and the promoted release stay attached to the project instead of being split across unrelated tools.
From source to release
Three steps keep the deployment path reviewable.
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
- 01
Start with source or a template
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios login - 02
Review the deployment contract
Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yaml - 03
Deploy and inspect the result
Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios up
adios.yaml
Your projectname: nestjs-api
build_cmd: npm ci && npm run build
start_cmd: node dist/main.js
runtime:
name: node@24
port: 8080
health_path: /healthzKeep the emitted entrypoint and health controller path aligned with the NestJS project structure.
Deployable starting points
Start NestJS from a template when the repository is not ready.
Start with a NestJS TypeScript project whose build, production entrypoint, port, and manifest are already connected.
API starters
Node.js NestJS
Express, Fastify, Hono, and NestJS starters with production-ready start commands.
TypeScriptnpm
- Template key
- node-nestjs
- Runtime
- node
- Repository
- templates
- Source path
- nodejs/nestjs
git clone https://github.com/adiosdotdev/templates.git
cd templates/nodejs/nestjs
adios upBefore production
Verify the workload.Then promote it.
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Ready when…
- npm run build emits the expected production files.
- The app binds to 0.0.0.0 and the declared port.
- The health controller reflects required dependencies.
- Configuration modules read secret-backed values.
Preview when…
- TypeORM or Prisma migrations modify production data.
- The app uses queues, scheduled jobs, or microservice transports.
- WebSocket gateways need connection-transition testing.
Questions, answered
What to know before deploying NestJS.
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
Can Adios deploy an existing NestJS project?
Yes. Run the Adios CLI from the project root, keep the repository and dependency files you already use, and add an adios.yaml file that describes the production build, start command, port, and health path.
Do I need Docker to deploy NestJS?
Not for a standard supported runtime. Use the project's normal production commands in adios.yaml. If the build needs unusual operating-system packages or native libraries, verify those dependencies in a preview before promotion.
Can NestJS queues and scheduled jobs run on Adios?
Yes. Keep worker commands and broker credentials explicit, then test retries, duplicate delivery, shutdown, and health independently from the HTTP application.
Can I deploy a NestJS monorepo?
Yes. Point the build and start commands at the selected application, and verify shared package installation plus emitted paths from a clean checkout.
What happens when the build or health check fails?
The candidate release keeps its build and runtime output for inspection. It must report healthy before it becomes the promoted version serving the application route.
Can I start from a template instead of an existing repo?
Yes. This page links to the closest official Adios NestJS starters. Inspect the exact source variant, deploy it in the console, or clone it locally and run adios up.
Related deployment paths
Connect the rest of the stack.
Deploy Node.js
Deploy a persistent Node.js web process or worker from its existing package scripts, with release health, logs, secrets, routing, and Git history attached.
Deploy Express
Run an Express API as a persistent Node.js process with its install command, port, health endpoint, secrets, logs, and promoted release connected.
Deploy PostgreSQL
Choose a PostgreSQL version, keep database credentials out of Git, attach persistent storage, connect the application, and verify data after a restart.
Deploy RabbitMQ
Start RabbitMQ with management access, protect broker credentials, connect publishers and consumers, and test acknowledgements, retries, and persistence.
The first release
Deploy NestJS with the source and evidence attached.
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.