Project setup

1. Drop the source. Place the purchased source/ directory at the root of your project, e.g. <project-root>/nitro-src/.

2. TypeScript config. Add a path alias so your own code can reach Nitro types:

   {
     "compilerOptions": {
       "paths": {
         "nitro-src/*": ["./nitro-src/*"]
       },
       "moduleResolution": "bundler",
       "target": "ESNext",
       "module": "ESNext"
     }
   }
   

3. Environment variables. Nitro reads from process.env at build time for preset selection and from runtimeConfig at runtime. Set NITRO_PRESET to target a specific platform:

   NITRO_PRESET=node-server   # or cloudflare, aws-lambda, bun, etc.
   

4. Wire Nitro into your project entry. Import createNitro from nitro-src/nitro.ts and build from nitro-src/builder.ts:

   import { createNitro } from "./nitro-src/nitro.ts";
   import { build } from "./nitro-src/builder.ts";
   

5. Use the CLI directly (after the package is installed):

   npx nitro dev    # dev server
   npx nitro build  # production build
   npx nitro preview
   

Public API

resolvePreset

import { resolvePreset } from "./nitro-src/presets/index.ts";

function resolvePreset(
  name: PresetNameInput,
  options?: PresetOptions
): Promise<NitroPreset>;

Call this to dynamically load the platform output preset by name. Used internally by createNitro but also useful when you need to inspect or extend a preset programmatically before passing it to the build pipeline.

PresetName / PresetOptions

import type { PresetName, PresetNameInput, PresetOptions } from "./nitro-src/presets/index.ts";

PresetName is the union of all supported platform identifiers ("node-server", "cloudflare", "aws-lambda", etc.). PresetNameInput is a looser form that also accepts aliases. PresetOptions carries per-preset configuration. Use these types to constrain config objects passed to your own wrapper around createNitro.

Type surface from types/index.ts

import type {
  NitroConfig,
  NitroHooks,
  NitroPreset,
  NitroBuildInfo,
  NitroRouteRules,
  NitroPrerenderRoute,
  NitroModuleInput,
} from "./nitro-src/types/index.ts";

The types/ barrel re-exports every public interface in the framework. Import from here instead of individual sub-files so your code stays forward-compatible as internal paths shift between beta versions.

Working examples

Scenario - Programmatic production build

A CI script that creates a Nitro instance with a specific preset and triggers a full build, then exits.

import { createNitro } from "./nitro-src/nitro.ts";
import { build, copyPublicAssets, prepare } from "./nitro-src/builder.ts";
import type { NitroConfig } from "./nitro-src/types/index.ts";

const config: NitroConfig = {
  preset: (process.env.NITRO_PRESET as any) ?? "node-server",
  rootDir: process.cwd(),
  output: {
    dir: ".output",
  },
};

async function main() {
  const nitro = await createNitro(config);
  await prepare(nitro);
  await copyPublicAssets(nitro);
  await build(nitro);
  await nitro.close();
  console.log("Build complete");
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Scenario - Resolving and inspecting a deployment preset

Useful when you need to validate that a target preset exists before kicking off a long CI pipeline.

import { resolvePreset } from "./nitro-src/presets/index.ts";
import type { PresetNameInput } from "./nitro-src/presets/index.ts";

async function inspectPreset(name: PresetNameInput) {
  const preset = await resolvePreset(name);
  console.log("Resolved preset:", JSON.stringify(preset, null, 2));
}

// Validate that the "aws-lambda" preset is available
inspectPreset("aws-lambda").catch(console.error);

Scenario - Running a named server task via the CLI task API

Nitro exposes server tasks as first-class primitives. The snippet below registers a task in your server code and then shows the equivalent CLI invocation.

// server/tasks/db-migrate.ts  (placed in your Nitro server routes root)
import { defineTask } from "nitro/task";

export default defineTask({
  meta: {
    name: "db:migrate",
    description: "Run database migrations",
  },
  async run({ payload }) {
    console.log("Running migrations with payload:", payload);
    // ... migration logic
    return { result: "ok" };
  },
});

# After `nitro build`, run the task:
npx nitro task run db:migrate --payload '{"env":"production"}'

File walkthrough

• cli/index.ts - Bootstraps the nitro CLI using citty, wires all subcommands via dynamic imports.
• cli/commands/ - Individual command implementations: dev, build, deploy, prepare, preview, docs, and the task sub-group.
• cli/commands/task/index.ts - Groups task list and task run under the task parent command.
• config/defaults.ts - Hardcoded default values for all Nitro config keys.
• config/loader.ts - Reads and merges nitro.config.ts / nuxt.config.ts from disk.
• config/update.ts - Mutates a live Nitro config after initial resolution (used by dev HMR).
• config/resolvers/ - One file per concern: paths, assets, storage, database, route-rules, unenv polyfills, tracing, tsconfig generation, etc.
• dev/app.ts - The H3 application used during development.
• dev/server.ts - Wraps srvx to run the dev server with HMR.
• dev/vfs.ts - Virtual file-system overlay for dev-mode generated files.
• prerender/prerender.ts - Crawls and statically renders all matching routes.
• prerender/utils.ts - URL normalisation and deduplication helpers for the prerender queue.
• presets/ - One subdirectory per deployment target, each exporting a NitroPreset object.
• runtime/ - Code that ends up inside the compiled server bundle (middleware, storage, cache, tasks).
• types/ - TypeScript-only barrel: config, hooks, fetch matchers, handler types, route-rules, build info, prerender, runner, module, srvx.
• utils/ - Shared helpers (logging, fs, rolldown plugin utilities).
• builder.ts - Orchestrates prepare → copyPublicAssets → build using Rolldown.
• global.ts - Augments global types and re-exports symbols needed at the top level.
• module.ts - defineNitroModule and the module resolution/execution pipeline.
• nitro.ts - createNitro: merges config, runs resolvers, instantiates hooks, returns the Nitro context.
• preview.ts - createDevServer wrapper for serving an already-built .output directory locally.
• routing.ts - Converts scanned handler files into H3 router entries.
• scan.ts - Glob-scans server/routes/, server/middleware/, server/plugins/ etc.
• task.ts - defineTask factory and the server-side task executor.
• vite.ts - Vite plugin factory that integrates Nitro's dev middleware into a Vite dev server.

Common pitfalls and fixes

• ESM-only output. Nitro v3 emits ESM. If your host project uses "type": "commonjs", add "type": "module" to package.json or wrap Nitro imports behind a dynamic import().
• moduleResolution must be bundler or node16. Older node resolution breaks imports of .ts extension paths; set "moduleResolution": "bundler" in tsconfig.json.
• NITRO_PRESET not set in production. Without it Nitro falls back to node-server; ensure the env var is injected in your CI/CD pipeline before running nitro build.
• Rolldown peer version mismatch. The beta uses a specific Rolldown snapshot; pin rolldown to the exact version in the upstream package.json to avoid subtle bundling breakage.
• unstorage driver auto-import. Storage drivers (Redis, S3, etc.) are resolved at runtime from unstorage; install the relevant driver packages separately (e.g. npm install unstorage ioredis) or the storage mounts will throw at startup.
• Task payload serialisation. Payloads passed via nitro task run --payload must be valid JSON strings; non-JSON values are silently ignored rather than throwing, which can cause confusing undefined payloads inside your task handler.

Vibe-coding prompt template

I have purchased the `nuxt-nitropack` AVCP block. The source lives at `./nitro-src/`
relative to my project root. I also have `USAGE.md` in the same directory.

Upstream package: user@example.com

My project is a Node.js TypeScript application (ESM, moduleResolution: bundler).

Please do the following step by step:
1. Read `USAGE.md` in full before doing anything.
2. Install all required dependencies listed in the "Required dependencies" section.
3. Update my `tsconfig.json` with the path aliases and compiler options described in "Project setup".
4. Create a `scripts/build-server.ts` that imports `createNitro` from `./nitro-src/nitro.ts`
   and `build`, `prepare`, `copyPublicAssets` from `./nitro-src/builder.ts`, wires them
   together, and respects the `NITRO_PRESET` environment variable.
5. Add `dev`, `build`, and `preview` npm scripts to `package.json` using the `nitro` CLI.
6. Show me how to add a server task using `defineTask` and invoke it with `nitro task run`.
7. For every step, show the exact file path and full file content. Do not skip files.

License and credit

Released under the MIT License (see source/LICENSE if present, or the upstream repository). Source: nitrojs/nitro - upstream npm package user@example.com.

This product’s unique contribution is clean room implementation of valuable code block into AVCP compatible standard.

The full install guide and integration prompts unlock after purchase.

Automation, Utilities & Developer Tools

Free