(disclaimer: Netlify employee) The big challenge with the cache interface atm is not using Redis (personally, I love Redis). It's that this interface is far from being a straightforward GET/SET/DELETE. Rather, you need to learn the default implementation and all its nuances (for different payload types), and duplicate/transform all the logic.

The division of labor between what the framework does and what the platform developers (or any other developer working on a high-scale/high-availability deployment) need to do, has to be fixed. If this happens - plus better docs - you should be able to "just use" Redis.

(disclaimer: I work at Netlify) It's not a 1:1 channel, we're pushing for as much work in the open as possible, and extending the OpenNext group to more members.

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)

Thank you for clarifying! There is a open source cache adapter but it does not support NextJS 15 at the moment.

Ooh, interesting. We didn't know about this. Is this it? https://github.com/caching-tools/next-shared-cache/tree/cana...

yes, there is even the official example here https://github.com/vercel/next.js/tree/canary/examples/cache...

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

Their whole class based hierarchy is really a bummer.