How to define custom presets?

[okikio]

I'm trying to create an experimental Nitro adapter for Bunny CDN, I've already created an experimental one for Astro, but I can't find any docs on actually creating a custom preset for Nitro maybe I'm looking in the wrong spot? From what I can tell the defineNitroPreset utils aren't actually publicly available, so I'm not actually sure how to go about doing this.

[yudin-s]

You are looking in the right area, but defineNitroPreset is an internal helper for Nitro's built-in presets, not the public extension point I would import from an external adapter package.

The supported surfaces I see are:

1. preset: selects a known generated preset name.
2. extends: can merge a preset/config layer, and the public config type allows an inline NitroPreset.
3. defaultPreset: can be a preset name or inline preset, but only as the fallback when no explicit preset / provider auto-detection wins.

So for a local experimental Bunny adapter, I would start with an inline preset/config layer instead of trying to register a new named preset:

// nitro.config.ts
import { resolve } from "node:path";
import type { NitroPreset } from "nitro/types";

const bunnyPreset = {
  extends: "base-worker",
  entry: resolve("./runtime/bunny"),
  commands: {
    preview: "bunny ...",
    deploy: "bunny ...",
  },
  output: {
    dir: "{{ rootDir }}/.output",
    publicDir: "{{ output.dir }}/public",
    serverDir: "{{ output.dir }}/server",
  },
  hooks: {
    async compiled(nitro) {
      // write Bunny-specific config/manifest files here
    },
  },
} satisfies NitroPreset;

export default defineNitroConfig({
  extends: bunnyPreset,
});

The important caveat is entry: built-in presets use defineNitroPreset() to resolve ./... entries relative to Nitro's internal presets directory. If your runtime entry lives in your adapter/app, resolve it yourself or make it package-resolvable.

If you want preset: "bunny" to work by name for everyone, that looks like an upstream Nitro preset addition rather than something an app config can register dynamically. For an adapter package, a Nitro module that applies extends, output, rollupConfig, and hooks is probably the cleaner reusable shape.

If this answers the custom-preset path, please mark it as answered so other adapter authors can find it.