Comment by Etheryte
3 days ago
I haven't really followed Next.js and the related ecosystem closely, what does this project do exactly? If I look at Next.js docs [0], they have three options for self-hosting: using a Node server, using a Docker container or as an SPA. Is this project a wrapper around one of those or is it something else entirely? Or to perhaps ask differently, to me it seems you can already self-host Next.js, what's the value add of this specific project?
[0] https://nextjs.org/docs/pages/building-your-application/depl...
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.
Gotcha. That means if I run Next for just frontend + server side rendering stuff then I can always self host it?
Sort of, so long as you don’t care about more complex hosting strategies eg hosting some/all of your server side code on edge servers when users visit your web app - as opposed to always sending them to a server in a set location in the world as a “normal” server architecture would typically do. Alongside not caring about prerendering and caching some pages and not others, that kind of thing
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.
(I work on Next.js)
The OpenNext project serves two purposes. First, it was to document some of the quirks when self-hosting Next.js. As of Next.js 15, the majority of these have been fixed, thanks to their feedback. The second is to provide an adapter for serverless Next.js deployments, similar to Vercel. Their adapter takes the Next.js output and transforms it to work in a serverless environment.
We're working with the maintainers of OpenNext to patch up some of the remaining quirks for deploying Next.js serverless and exploring how to make the maintenance of these community adapters easier.
If you want to self-host Next.js on a server, like a VPS or Node.js server, all features of Next.js are supported[1] and you do not need to use OpenNext. Our self-hosting docs include 10 example repos for deploying to different providers and a video walking through all features and options of Next[2].
[1]: https://nextjs.org/docs/app/building-your-application/deploy... [2]: https://www.youtube.com/watch?v=sIVL4JMqRfc
Hello! On this topic: Could you please look into making the path ‘next/image’ uses for caching images user definable? Currently I can’t use Google app engine standard because the directory it uses is write protected. The only real solution seems to be custom image providers, which is a drag, so I’m on App Engine Flex spending way more than I probably should :-)
1 reply →
(I work on Firebase App Hosting, which also supports Next.js directly rather than OpenNext)
I want to +1 that Vercel has been really improving their portability. We still have Next.js specific code in Firebase, and having different architectures can sometimes make us have to figure out the best mapping of their features, but Vercel has made a noted effort to improve encapsulation of Vercel-specific features and portability has improved. I’m honestly surprised that OpenNext, which is not a new project, seems to have gained a lot of attention in the immediate past.
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.
What’s the CTO’s motivation for migrating off of Next.js? And to what?
Next is actively a bad stack run by an incredibly shady company would be a good start
2 replies →
Didn't get far enough along to understand the motivations and considered alternatives.
> especially given the CTO's desire to also migrate off of Next.js
To Remix?
Didn't get far enough along to understand the motivations and considered alternatives.
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.
Ultimately what you’re doing is scalable for most use cases. You can even horizontally scale that setup on the fly to mimicking what you would get from using next in a serverless environment.
I believe the intent of OpenNext is to allow you to run your Next.js applications in a serverless manner, same as Vercel.