Use a supported Nuxt branch and compatible Node runtime. Confirm persistent Node hosting, the assigned listener and any native dependencies required by the application.

1. Install the locked dependencies and choose the Nitro Node-server preset appropriate for the deployment. Run the application’s production build.

2. Deploy the complete generated output required by that preset. For the standard Node-server output, the entry point is .output/server/index.mjs.

3. Set the production environment and the listener variables supported by the preset and hosting integration. Keep private runtime configuration outside browser-visible values.

4. Start the entry point through the approved process manager and connect the public HTTPS hostname through the reverse proxy.

5. Test the server endpoints, rendered pages and assets, then record the restart and previous-release recovery procedure.

Open a page directly and navigate to it from another page. Call a harmless server endpoint and confirm the application returns after a controlled process restart.

If only static files work, the server process or proxy may be missing. If the process starts but URLs are wrong, inspect base-path and runtime configuration.

A build can finish successfully even when the production process never starts. Check the hosting application configuration for the selected runtime, working directory and startup command appropriate to the project's deployed output.

Then test three layers: the process starts without an error, the hosting route reaches it, and the public HTTPS page behaves correctly. If the public route shows a gateway error while the process log says it is listening, investigate the assigned port and proxy integration rather than repeatedly rebuilding the application.

Where should environment settings go?

Use the hosting platform's supported environment configuration or approved secret storage. Values intended for browser use must be treated as public. Keep database credentials and private API keys on the server side. Do not assume a variable remains secret merely because its name appears in a configuration file.

Test restarts and a fresh deployment in staging, and retain a known-good release for rollback. Send us the startup error, runtime version, deployment mode and relevant public URL when requesting help. Redact tokens and secrets from logs. We can investigate the hosting interface without needing your entire production environment copied into a ticket.

• Publishing a prerendered Nuxt website
• Setting Nuxt public and private runtime configuration
• Starting a Node app with the assigned production port
• Deploying a Vite site under a subdirectory

• Nuxt deployment
• Nuxt configuration