Nuxt
What Gigadrive Network detects in a Nuxt project, which Nitro output it expects, and why the Nitro preset is pinned during the build.
Gigadrive Network detects Nuxt from nuxt in package.json and deploys the Nitro server Nuxt
builds into .output. Nothing in your project needs to change for that, as long as the build leaves
.output where Nitro's Node preset puts it.
What the preset configures
| Setting | Value |
|---|---|
| Runtime | node-22 |
| Memory | 256 MB |
| Maximum duration | 30 seconds |
| Function | .output/server/index.mjs, serving /* |
| Assets directory | .output/public |
| Environment | NODE_ENV=production, NITRO_PRESET=node-server |
The preset walks .output/public after the build and publishes every file inside it, so Nuxt's
client bundle reaches the edge with no configuration of your own.
Frameworks covers how a preset resolves its assets directory.
The pinned Nitro preset
The build environment sets VERCEL=1, because a long tail of ecosystem packages branch on it. Nitro
reads that same variable and would switch itself to the Vercel preset, which writes to
.vercel/output and leaves .output empty. The build therefore pins NITRO_PRESET=node-server
before your own variables are applied, so .output stays where the preset expects it.
You can still set NITRO_PRESET yourself, as an environment
variable on the application or environment, since your values are
applied after the platform's defaults. Another preset moves the build output somewhere else. If
nothing lands at .output/server/index.mjs, the deployment stops before packaging with a message
naming the file it could not find.
Build cache
.nuxt/cache is wired into the build cache, so a rebuild reuses
Nuxt's incremental state along with the package manager store. Changing any environment variable
invalidates that cache, since the variables are part of its key.
Nuxt documents its own build output and deployment presets at nuxt.com/docs.
