(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 :-)

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