`npm start` is just whatever you tell it to do - eg `node ./src/index.js`, and yes that is plenty production-ready - you don't need any special thing, it's not like Ruby etc

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

React runs webpack by default. Are you telling me there are large prod websites running on a dev server in kubernetes somewhere? Because I'd definitely not feel confident putting that into production. (I am genuinely curious how is FE run nowadays with cloud-native stacks)

And of course TLS termination and load balancing aside, you do that in your orchestration platform (so, Kubernetes typically).

In Next.js there are only four commands:

- `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)

What's the difference between `next build` and `next export`? I couldn't tell from reading your comment.

`next build` makes a server that needs to be run with nodejs. Dynamic pages keep being JS code. the fact that some pages are optimized down to html is an internal implementation detail.

`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.

Within create-react-app, the local dev server does indeed use Webpack. For deploying into prod, the recommend approach is to use the `build` script which will output the static files to be deployed to a host e.g. S3 or Zeit Now.

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.