Standalone output is a packaging mode, not a hosting platform. It traces the files your production server needs and writes a minimal runnable release to .next/standalone.
Configure the build
Set output: "standalone" in next.config.js, install from the lockfile, and run the normal production build. Test the generated server with the same Node.js major version and environment categories you intend to use in production.
The trace is rooted at the Next.js project by default. In a monorepo, files outside that root may need outputFileTracingRoot; runtime files missed by tracing may need narrow outputFileTracingIncludes rules.
Assemble a complete release
The generated directory contains a minimal server.js and traced dependencies. It does not copy public or .next/static by default. Copy those directories into the standalone tree when the Node.js server will serve them, or publish them through a CDN with a deliberately configured asset path.
Keep build-time and runtime values distinct. Variables prefixed with NEXT_PUBLIC_ are embedded during the build and cannot be changed by updating only the runtime environment.
Operate the server
Run server.js with a process supervisor, an explicit host and port, and a non-root service account. Put Nginx or another reverse proxy in front of the process for TLS, request limits, and public network controls. If the application streams responses, verify that every proxy layer passes the stream instead of buffering it.
Use a release directory or immutable image so a failed deployment can switch back to the previous artifact. A successful process start is not enough: request a representative dynamic route, a static asset, an optimized image, and a health endpoint before directing production traffic to the release.