Fastify Vite: Running Vite Inside Fastify Without a Second Server
Fastify plugin for Vite integration. This repository is also the home of @fastify/vue and @fastify/react.
At a glance
- What is it?
- The @fastify/vite plugin mounts Vite's dev server as Fastify middleware and serves the production bundle from the same process. A look at how it works, what the Vue and React wrappers add, and where the trade-offs sit.
- Who is it for?
- Adopt @fastify/vite if you already run a Fastify server and want Vite's dev experience inside that same process, with a production bundle served from the same route. Skip it if you need a full meta-framework like Nuxt or Next.js, or if you prefer the conventional two-server setup with a reverse proxy.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the plugin actually solves
Most Vite projects run Vite's dev server on its own port and proxy API requests to a backend. That works, but it means two processes, two ports, and a proxy configuration that can drift. @fastify/vite takes the opposite route: it runs Vite's development server as middleware inside a Fastify server. In development, a request to your Fastify app is handled by Vite, so hot module replacement and React or Vue transforms happen in the same process as your backend. In production, the plugin serves the built bundle from the Vite configuration file, so you do not need a separate static file server. This is for teams that already standardize on Fastify and want to keep the frontend build tooling close to the backend, not for people who want a standalone frontend stack.
The mechanism: middleware in dev, static in prod
The README is explicit: in development mode, the plugin runs Vite's dev server as middleware. That means Vite's transform pipeline, dependency pre-bundling, and HMR websocket all live inside the Fastify request lifecycle. In production, the plugin infers the output from a Vite configuration file and serves those files directly. The plugin exposes the Vite application to your Fastify application, and it provides configuration hooks to ease router integration. Those hooks are the key abstraction: instead of hard-coding a route for every page, you can wire Vite's module graph into Fastify's router. The README does not detail the hook signatures, so you have to look at the e2e examples to see how they are used. The design is intentionally low-level, which gives you control but also means you are responsible for the glue.
Getting it running: packages and starters
The repository is the home of three packages: @fastify/vite, @fastify/vue, and @fastify/react. The core plugin is @fastify/vite, and the other two build on it to provide Nuxt-like and Next.js-like functionality, respectively. The README points to official examples in the e2e/ directory for low-level integration, and to starters in the starters/ directory for a more developer-experience-focused setup. The actual install command is not in the README, but the package names are clear: you would add @fastify/vite to a Fastify project, or choose @fastify/vue or @fastify/react if you want the framework-specific conveniences. The configuration is done through a Vite configuration file, which the plugin reads to infer the production bundle. There is no CLI tooling mentioned; you wire the plugin into your existing Fastify server setup.
The Vue and React wrappers: what they add
@fastify/vue and @fastify/react are not separate products. They are thin layers on top of @fastify/vite that mimic the structure of Nuxt and Next.js. The README says they provide basic Nuxt-like and Next.js-like functionality. That word, basic, matters. You get file-based routing and server-side rendering conventions, but you do not get the full feature set of Nuxt or Next.js, such as nested layouts, middleware, or a large plugin ecosystem. The wrappers are useful if you want a familiar mental model but want to stay inside the Fastify ecosystem. The trade-off is that you are betting on a smaller community and a smaller set of examples. The recent releases show active maintenance, with @fastify/react at version 1.2.2 and @fastify/vue at version 2.0.1, but the README does not list the exact features each wrapper provides.
A real limitation: thin documentation and low-level glue
The README is short. It gives you the three bullet points, the team, and the license. It does not explain the configuration hooks, the router integration mechanism, or the exact differences between the core plugin and the wrappers. The repository layout suggests that the e2e examples are the de facto documentation, which is fine for experienced developers but a barrier for newcomers. The biggest limitation is that you must own the integration. If you use the core plugin, you need to write the code that connects Vite's module graph to Fastify's routes. The wrappers reduce that work, but they are still not drop-in replacements for a meta-framework. This is the wrong tool if you want a batteries-included framework with a large community and extensive guides. It is the right tool if you are comfortable reading example code and writing your own glue.
Alternative: the two-server approach with a proxy
The conventional alternative is to run Vite's dev server on its own port and a Fastify server on another, with a proxy in front or in the Fastify server itself. That is the approach most Vite templates use, and it keeps the frontend toolchain completely separate from the backend. The difference is architectural: @fastify/vite collapses two processes into one, which simplifies deployment and avoids CORS and proxy issues in development. The two-server approach keeps concerns separated, so you can swap the backend without touching the frontend tooling, and vice versa. The trade-off is operational: two processes to manage, and a proxy that can fail. For a small team that owns both sides, the two-server approach is simpler to reason about. For a team that wants a single process in production and a single dev command, @fastify/vite is the more direct path.
Maintenance and license implications
The repository is not archived, and the last push is from July 2026, with releases for all three packages in the same week. That signals active maintenance, though the README does not include a changelog or a migration guide. The license is MIT, which means you can use it in commercial projects without copyleft obligations, but you should read the license text yourself for any specific legal questions. The maintenance cost for you comes from the thin documentation: when you upgrade Vite or Fastify, you may need to check the e2e examples to see how the integration changes. The plugin is tied to the Vite version it supports, and the README does not state which Vite versions are compatible, so you must verify that against the package's peer dependencies before upgrading.
Editorial conclusion
Adopt @fastify/vite if you already run a Fastify server and want Vite's dev experience inside that same process, with a production bundle served from the same route. Skip it if you need a full meta-framework like Nuxt or Next.js, or if you prefer the conventional two-server setup with a reverse proxy. Before adopting, verify that the plugin's configuration hooks match your router integration needs, and check the exact Vite version supported by the latest release. The plugin is MIT licensed and actively maintained, with recent releases for all three packages, but the documentation is thin, so plan to read the e2e examples and starter templates to understand the integration points.
Community notes