Deploy Nuxt on Nodion

Deploy Nuxt step by step

1. Keep the default scripts and a lockfile Commit your lockfile; the build fails without one. Nuxt projects ship no start script, and you do not need one: Nodion runs your build script and then starts .output/server/index.mjs, which listens on the PORT that Nodion sets. If you add a start script, Nodion runs that instead. package.json

   "scripts": {
     "build": "nuxt build",
     "dev": "nuxt dev"
   }

2. Create the app In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository, pick the branch and the region EU Central, and keep the build strategy on Buildpacks.
3. Configure with NUXT_ variables Declare your settings in runtimeConfig and set them as NUXT_API_SECRET or NUXT_PUBLIC_API_BASE on the Environment tab. Nuxt reads these when the server starts, so they need no Build flag. Only values that nuxt.config reads from process.env during the build need it. nuxt.config.ts

   export default defineNuxtConfig({
     runtimeConfig: {
       apiSecret: "",
       public: {
         apiBase: "",
       },
     },
   });

4. Push to deploy Every push to the branch builds a new release. Traffic moves to it once / answers with a 2xx or 3xx status. If / answers 401 or 404, add a server route such as server/routes/health.ts and set /health as the health check path in the app settings.

Good to know

• Static site with nuxt generateNodion does not detect nuxt generate on its own and keeps starting the server. For a static site, make nuxt generate your build script and add a static.toml with output-dir = ".output/public". Nodion then serves that folder with a static web server and an index.html fallback, and the smallest size is enough.
• Nitro presetNodion starts .output/server/index.mjs, which Nitro's default node-server preset writes. If nuxt.config or NITRO_PRESET picks a preset for another host, remove it.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Preview Environments Explained: An App per Pull Request A running copy of your app for every pull request: what preview environments are good for, where they get tricky and how Nodion handles them.
• Cloud Native Buildpacks Explained Buildpacks turn your source code into a container image without a Dockerfile. What they are, and how they work.

Nuxt on Nodion: questions and answers