Host Nuxt SSR with Node: build and deployment checks

Nuxt can generate static files or run a Node.js server. The right mode depends on how your application handles routes, data and server code. Do not switch to static output just to simplify hosting if that removes features your site needs.

This guide prepares Nuxt’s Nitro Node output and explains what to check when connecting it to Hostbrid Projects. Projects supports Node services and containers subject to plan and resource limits; review current plans and prices before choosing. This guide does not claim that every Nuxt module works unchanged.

Choose between static rendering and a server

nuxi generate prerenders eligible routes and places public output in .output/public. A Node server is the option for pages rendered per request, server endpoints or functions that depend on Nitro. Nuxt describes both paths in its official deployment guide.

Review nuxt.config, package.json, modules and routes using defineEventHandler before changing modes. If the project needs request-time rendering, cookies or secrets available only on the server, do not replace SSR with static HTML without checking each feature.

Build and test the Node server

Keep the lockfile and use the package manager that created it. For an npm project:

npm ci
npm run build
NODE_ENV=production node .output/server/index.mjs

Nitro’s node-server preset creates .output/server/index.mjs; Nuxt documents port 3000 as the default and supports PORT and HOST. Locally, try PORT=3000 HOST=127.0.0.1 NODE_ENV=production node .output/server/index.mjs and check the home page, a dynamic route and a missing URL. Use the actual build script in your package.json; if it runs another command, understand why before copying these instructions.

Keep variables private

Nuxt separates private runtimeConfig from runtimeConfig.public. NUXT_PUBLIC_* variables are exposed to the browser and must not contain passwords, provider keys or admin tokens. Set secrets in the service’s private configuration, not in Git or code bundled for the browser. Nuxt’s runtime configuration guide explains how configuration maps to environment variables.

Deploy and check routes

Connect the repository in Projects, select the right branch and set the build, start command and runtime for the application and plan. If the service preset does not match Nitro’s artifact, provide a Dockerfile that runs npm ci, npm run build and starts node .output/server/index.mjs; configure the port exposed by the container. Do not copy a generic setup without checking the repository’s Node version and package.json.

Start on the temporary domain. Check actual SSR, routes with and without trailing slashes, assets, forms, authentication, API calls and logs. Then configure the final domain and repeat the checks over HTTPS. If you only need prerendered pages, compare static output with Sites and avoid running a process you do not need.

Local check (9 October 2026): a minimal Nuxt 4.6.0 app built with the node-server preset; node .output/server/index.mjs served its home page with HTTP 200 and a missing route with HTTP 404. This example was not deployed to a Projects account, and third-party module compatibility was not tested.

References: Nuxt deployment, runtime configuration, Projects and current plans.