IMHO one major challenge is the amount of work one has to do to build an adapter, if we can make the spec leaner and move logic out of e.g. the CacheHandler, that's gonna make it easier for you to create your own (or you could state that some features/modes are not supported - but for that, you'd need to have a very good idea of what these even are)
but it does not work because of NextJS 15.
I changed the example to point to latest NextJs 14 and fixed some cache-handler bugs it works fine, and I deploy it successfully with DollarDeploy to DO VPS https://github.com/huksley/next-cache-handler
Our hope is that the OpenNext initiative's growth and connections with the Next.js team is just a first step toward shifting some Next.js governance out to the open. The article calls out that the OpenNext members are hoping to contribute to public RFCs in the future, with Next.js core team collaboration.
So instead of having it in open, Netlify now have their own channel of communication with Vercel. This still continue to feel like a closed garden and makes it difficult for small vendors to have proper NextJS hosting.
(Disclosure: I am running DollarDeploy which allows hosting NextJS (amongst others) on your own server. And we don't use docker!)