> The official methods for self-hosting Next.js require running the application in a stateful way, as long-running servers. While technically possible, this is

> The official methods for self-hosting Next.js require running the application in a stateful way, as long-running servers. While technically possible, this is very hard to operate in any real-world production environment where a single instance isn’t sufficient. Come on, this is a patently false statement. There's nothing inherently stateful about Next.js deployment, and self-hosting is both thoroughly documented and straightforward: https://nextjs.org/docs/pages/building-your-application/deploying#self-hosting https://nextjs.org/docs/pages/building-your-application/depl... If you've worked with any modern deployment pipeline, you'd know self-hosting Next.js is no more complex than any other React application. You build it, you deploy it, you scale it with standard practices. For many teams with existing infrastructure, self-hosting is actually simpler than migrating to a platform like Vercel. This kind of misinformation reads like someone who either hasn't actually tried self-hosting or has some agenda against the approach. > The setup needs to be able to dynamically scale up very quickly in order to handle sudden bursts of traffic, while at the same time being able to scale down to zero in order to be cost-effective. This is obviously a non-issue with the vast majority of deployed apps as a even a single nextjs instance will be able to trivially handle thousands of requests per second.