Nitro V3 / Deploy Adapter

[aheissenberger]

How about adding a second middleware adapter which works with nitro api which expects more or less a fetch handler and than have the ecosystem of nitro adapters available for deployment? The latest version is now a vite plugin.

https://v3.nitro.build

Here is also an example of adapting the old V2 version as a vite plugin:
https://github.com/hi-ogawa/vite-plugins/tree/main/packages/nitro

[lazarv]

Thanks for the suggestion, I've actually spent quite some time thinking about Nitro in this context.

One direction I explored was having something like a react-server-adapter-nitro, where the first step would be transforming a react-server build into a Nitro app, and then delegating the final output to Nitro's own deployment adapter ecosystem. On paper this looks like a very clean integration point.

In practice, though, I was not able to make this work in a convincing way. The current Nitro configuration and hook surface doesn't expose enough of the build and runtime lifecycle to express everything react-server needs, and once react-server is treated as "just another Nitro app", a lot of assumptions start leaking in both directions. At that point the abstraction becomes fairly fragile, and it's hard to reason about where certain responsibilities should live.

That said, the longer-term direction I would like to move toward is not to reject Nitro, but to make react-server itself more modular. Ideally, its core pieces should be usable directly with Vite or Nitro as libraries, rather than only through a standalone meta-framework. Getting there would require fairly deep refactoring, and at the moment I don't see that work as a short-term priority.

For deployment specifically, the current approach is intentional. I want to keep react-server-adapter-core as the stable abstraction layer and implement deployment adapters directly against that. Where it makes sense, Nitro adapters and patterns can absolutely serve as a reference, or even be partially reused or generated, but without forcing react-server to fit into Nitro's model prematurely.

So I'm definitely not ruling out Nitro integration, I just don't think wrapping react-server inside Nitro is the right first step. A more modular react-server that can later be embedded into Nitro or Vite feels like a more sustainable path.

Thanks for sharing the links and ideas, they were very useful context.