Deploy
Nitro can generate different output formats for different hosting providers from the same code base. Using built-in presets, you can adjust the output format with little to no extra code or configuration.
Default output
The default production output preset is Node.js server.
In development mode, Nitro always uses a special nitro-dev preset that runs your app with Node.js (ESM) in an isolated worker environment, matching production behavior as closely as possible.
Zero-Config Providers
When deploying to production using CI/CD, Nitro tries to detect the provider environment and set the right preset automatically, with no configuration required. The following providers can be auto-detected with zero config:
--env-mode=loose flag).Other built-in providers are available with an explicit preset, including Zephyr.
Changing the deployment preset
To build for a specific provider, set the NITRO_PRESET environment variable, update your Nitro configuration, or use the --preset argument.
The environment variable approach is recommended for CI/CD deployments.
Example: Using the NITRO_PRESET environment variable or the --preset argument
NITRO_PRESET=cloudflare_pages nitro build
# or
nitro build --preset cloudflare_pages
Example: Updating the nitro.config.ts file
import { defineConfig } from "nitro";
export default defineConfig({
preset: 'cloudflare_pages'
})
Compatibility date
Deployment providers regularly update their runtime behavior. Nitro presets are updated to support these new features.
To prevent breaking existing deployments, Nitro uses compatibility dates. These dates let you lock in behavior at project creation time. You can also opt in to future updates when ready.
When you create a new project, the compatibilityDate is set to the current date. This setting is saved in your project's configuration.
You should update the compatibility date periodically. Always test your deployment thoroughly after updating. Below is a list of key dates and their effects.