You can "self-host" as in `next build` and `next serve`, but it runs as a monolothic runtime. Next-on-vercel compiles each api route to a serverless function and supports various additional flavours of server side rendering of pages. Open Next is being able to run like Next-on-vercel but on AWS, your own infra, Cloudflare Workers, and others.

The reason this project is important is because Next.js is hard to deploy if you're not using Vercel to host your app. You can easily run into issues that are hard to resolve. It's creates lock-in with Vercel and is one of the reasons why Vercel has a bad rep.

In the company I just left, I actually went through the process two or so months ago of migrating their Vercel deployment to AWS. I evaluated several options that are listed on the website and on GitHub, and we landed on using OpenNext via SST, it was a low-pain effort, especially given the CTO's desire to also migrate off of Next.js.

As other commenters have touched on - my understanding is the purpose of OpenNext is to package the output artifacts of a Next build in a way that can be deployed to a serverless environment, analogous to how Vercel does it. The supporting projects like SST and the other links in the repo are to take those OpenNext artifacts and deploy them to infrastructure generally in an opinionated way - additionally supporting some of the "extra" features described in the repository.

The last project I was working on was to then migrate from SST to Fargate, as a persistent process (serverful?) deployment was preferable for various reasons. In that scenario, we would just be running the built in server using the Next.js standalone deployment mode (effectively a `node index.js`). We didn't need the extra functionality covered by OpenNext.

Confused as well since we self host in docker and it's no different than any other node app. People keep posting that there's gotchas and weird setups but... it just works well for us.

I believe the intent of OpenNext is to allow you to run your Next.js applications in a serverless manner, same as Vercel.

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.

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

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.

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

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.

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

The very link you posted says you can use the Node runtime, you're not limited to Edge runtime.

OpenNext is just for packaging the Next.js build artifacts. The infrastructure is defined by projects that deploy those artifacts, examples here: https://opennext.js.org/aws/get_started

Some of them are, for example, Terraform projects that list the specific infra. I have experience with the SST deployment, whose website unfortunately doesn't do a great job of listing the infra architecture.

The biggest cost for us on Vercel (several hundred dollars a month) was Image Optimization, and that was because the app was being majorly inefficient with images, in part due to some default behavior in Next.js that we found unfriendly [0], and in part due to negligence. That being said, it wasn't "cheap" by any means outside of that, still hundreds a month for something that I would not consider a high traffic application (I wish I could remember more specific numbers).

Migrating to OpenNext using SST, I think we got the bills for compute and asset serving down to like $15/day or something (granted, we spent expensive engineer time on the migration).

[0] https://nextjs.org/docs/app/api-reference/components/image#s...

It offers packaging for deploying to a serverless environment (e.g. Lambda) analogous to how Vercel does it.

The last question is salient, and it's possible for OpenNext to break and have to catch up to changes in Next.js, though I believe there's some more direct collaboration. I'd say that's the biggest downside - it's not guaranteed compatibility.

I did a migration recently (comments elsewhere in this post), and I don't recall the specific issue, but I _do_ recall running into at least one scenario where OpenNext had made a decision that impacted - in a way that was visible to me and undesirable - how Next.js functioned. That's not a criticism, there's tradeoffs.

llrt is extremely experimental and early - probably not the right fit

the latter is being worked on and there is a cloudflare adapter in that github org