And of course TLS termination and load balancing aside, you do that in your orchestration platform (so, Kubernetes typically).
- `next dev` starts the dev server with unoptimized code and webpack hot-reload
- `next build` compiles all your code to be ready for production (optimizations enabled and not hot-reloading, pages that aren't dynamic server-side get turned into regular HTML, etc)
- `next start` serves that production-ready bundle, with a bare-bones (but production-ready) server
- `next export` forces every page to compile down to HTML and gives you a folder of static markup and js you can upload to any static host
So yeah, `next start` is indeed production-ready, and similar to what major websites already do. (Also there's no soft, hard, or default dependency between webpack and react, but the starter template uses it to make life easier for devs)
`next export` makes a folder of static resources (HTML, packages client JS code, CSS). It also forces every page (even dynamic ones) to compile down to HTML.
If you require server-side rendering, Next.js can be run just as any other Node server so will be fine in Docker. Alternatively, Next has support for running in AWS Lambda/Lambda@Edge do you don't need to have infra running 24/7.
However, regardless, you should really put it behind a load balancer of some kind, and it's generally best to do your TLS termination in that too.
And you'll want something to manage the application and make sure it's running etc as normal. Usually the cleanest option is to have it wrapped up in a Docker image being managed by an orchestrator, but there's also options like pm2