NestJS

Gigadrive Network detects NestJS from a @nestjs/core entry in the dependencies or devDependencies of your root package.json. The compiled server becomes one Function that answers every path.

Defaults

NestJS is detected ahead of Hono, Fastify, Elysia and Express, and behind Next.js and Nuxt.

The entrypoint

The entrypoint is main.js inside your Nest output directory. The preset reads nest-cli.json for compilerOptions.outputPath, falling back to the default project's output path, then to the first project's, then to dist. A path that escapes the project root is ignored and dist is used instead.

That file has to exist when packaging starts, so scripts.build in your package.json must produce it. The standard "build": "nest build" from the Nest CLI does. Without a build script the build logs No build script found in package.json, skipping build and the deployment then fails on the missing entrypoint.

Nest calls app.listen() from an async bootstrap() that resolves after the module finishes importing. The Node runtime keeps watching for that call for 15 seconds after the import, captures the server, and forwards requests to it. The port you pass to listen() is ignored, and the capture is what lets Nest WebSocket gateways accept upgrades.

Changing the defaults

A dependency-injection graph the size of a real Nest application is the usual reason to raise memory:

version: 4
functions:
  dist/main.js:
    runtime: node-22
    memory: 1024
    max_duration: 60

Declaring a functions block replaces every entrypoint the preset produced, and settings you leave out fall back to the config file's defaults of memory: 128 and max_duration: 30 rather than the preset's 256 MB. Set both explicitly. See Memory and CPU for what memory buys you.

NestJS documents its own API at docs.nestjs.com.