Show HN: Self-Host Next.js in Production

I've been surprised by the number of companies adopting nextjs as their defacto framework without concern for the uncomfortable reality that the framework is built to be hosted on vercel with self hosting largely supported as an afterthought. It's great that opennext exists, but it really shouldn't _have_ to exist (as I believe some of the maintainers have publicly stated)

Next, as is, works fine self hosted? Certainly not everyone needs serverless functions split out like Vercel does.

I’m more surprised because it often feels like Next is slowly rediscovering the last 20 years of web frameworks in janky, somewhat broken steps.

I’m uncomfortable using most JS frameworks. The churn is so high and something new comes out every couple of years.

At the risk of sounding like a grumpy old developer, I am currently using minimal JS, native when possible and jquery as needed. The UX is just fine. Some pages have interactive JS but most reload the page. I have a hard time imagining this isn’t an option for most web apps.

Deploying next.js on containers, AWS Amplify, digital ocean, Netlify, etc is trivial. Such a strange statement to read.

It is all about the scale.

It doesn't have to exist - I run next.js self hosted and it's arguably better than hosting on vercel (no cold starts, dedicated cpu, next to my api server/db).

Remix is growing, and when react router 7 lets you add SSR into any react SPA, I would guess next's market share will slowly shrink in part for that reason

I don't know why people keep saying this. There are some features of Next.js that are better supported on Vercel. That doesn't mean that you have to use Vercel. In fact if you are just building a static React site without any server components (so, 99% of sites created with Next.js) then it makes literally no difference where you deploy it.

It is fine to sound like a grumpy old developer. We have clients using nextjs and it might have its place if you have apps in active development with dedicated teams, however for LoB apps for instance that don't change a lot and/or don't have continued dev or a dedicated team over time, it's a bad choice imho. Personally, I consider it a terrible choice always, because of the churn mostly; the current info in SO and LLMs is often wrong because of that churn. Best practices change and you have to pin everything or things auto-break. We get hired for a lot of $ to fix that in emergence settings, but I rather would have that people not use this stuff at all. It's not even a good dev experience imho, but I guess that's personal as either others are resume-devving and lying or just have another idea about what is a nice experience.

... which no-one (rounding error in % of companies) needs.

> somewhat broken

bit of an understatement there