Zum Inhalt springen
GigadriveDocs

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

SettingValue
Runtimenode-22
Memory256 MB
Maximum duration30 seconds
Function.output/server/index.mjs, serving /*
Assets directory.output/public
EnvironmentNODE_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.