Confirm the supported Node version, memory available during build and runtime, and the application’s selected output mode. Keep a tested previous release.

1. Install the locked build dependencies and run the application’s production build. Resolve build errors before replacing the live release.

2. For a normal Node deployment, start the built application through its production command, commonly next start, with the assigned listener configuration.

3. If using standalone output, deploy the traced runtime output and the required public and static assets according to that mode’s instructions. Do not assume every repository file is included automatically.

4. Set private runtime configuration through the approved secret store or panel. Use the same build consistently across instances serving the release.

5. Supervise the process, configure the reverse proxy and health checks, then switch traffic through the supported deployment mechanism.

Test direct and client-side navigation, a server-dependent action and the expected assets. Confirm the process restarts cleanly and the public endpoint serves the intended release identifier.

Missing assets can indicate an incomplete standalone package or a mismatched build. A startup memory failure needs a resource and build architecture review rather than a development-mode fallback.

• Choosing a static export or a Next.js server deployment
• Protecting a Next.js deployment with a reverse proxy
• Deploying with a release directory and a controlled switch
• Building Next.js with the right public environment values

• Next.js self-hosting
• Next.js output configuration