fastify-vite: serving a Vite app from a Fastify server

The problem fastify-vite solves for Fastify users

A Vite frontend and a Fastify backend normally run as two processes on two ports. That means a proxy in development, a separate static file host or CDN in production, and two deploy steps that have to stay in sync. @fastify/vite collapses that into one Fastify server. The README states the plugin lets you run Vite's development server as middleware in your Fastify server, in development mode only, and automatically serve the Vite production bundle inferred from a Vite configuration file.

The audience is narrow and specific: teams that have already chosen Fastify for their HTTP layer and Vite for their frontend, and who want the two to share a process rather than talk over a proxy. If your backend is Express or your frontend is already inside Next.js, this plugin is not aimed at you. The repository also hosts @fastify/vue and @fastify/react, which the README describes as providing basic Nuxt and Next.js-like functionality through @fastify/vite. Those two packages are the higher-level entry point, and the plugin itself is the layer underneath them.

How the dev middleware and production bundle handoff works

The mechanism has two modes and the split is the whole design. In development, the plugin mounts Vite's dev server as Fastify middleware, so requests that Fastify receives are handed to Vite for transformation, which is what gives you hot module replacement without a second process or a proxy rule. In production, the dev middleware is absent, and the plugin serves the built bundle instead, inferring the output from the Vite configuration file rather than from a path you pass in.

The README also mentions configuration hooks that exist to ease router integration and other customizations. That phrasing matters. The plugin does not impose a routing convention on your frontend. It exposes your Vite application to your Fastify application and gives you hooks to connect the two, which means the mapping from Fastify routes to frontend entry points is something you write. This is the opposite of the Next.js model, where the file tree is the router. Here the file tree is yours and the glue is yours.

The repository layout reflects that split. The e2e/ directory holds what the README calls official examples of low-level integration, and starters/ holds the DX-focused starters built on @fastify/vue and @fastify/react. If you are learning the plugin, the e2e examples show the raw shape of the integration and the starters show what it looks like once someone has made the routing decisions for you.

Installing @fastify/vite and running a first dev server

The plugin is published as @fastify/vite. The repository is a pnpm workspace, and the root package.json pins packageManager to [email protected], so the project's own tooling assumes pnpm. The README gives no install command and no registration snippet, so the only code that can be shown verbatim is the workspace script names from the root package.json.

pnpm --filter './packages/*' run --if-present build
pnpm --filter './packages/*' run --if-present test
pnpm --filter './e2e/*' run test

Those three lines are how the repository itself builds the packages, runs their tests, and runs the end-to-end suite in e2e/. If you want to read a working integration rather than assemble one, the README points at e2e/ for official low-level examples and starters/ for the DX-focused starters built on @fastify/vue and @fastify/react. Cloning the repository and running the e2e script is the closest thing to a first real use that the documentation supports.

For your own application, the README does not document a registration call, an option object, a port, or an environment variable, so none of those appear here. Confirm them against the project's documentation site and the e2e examples before you write your server.

Where the low-level approach costs you

The plugin's restraint is also its sharpest edge. Because router integration is left to configuration hooks, a team that wants file-based routing, server-side data loading and a defined build output gets none of those by default. You get Vite running inside Fastify and a production bundle served from a Vite config. Everything above that line is your code. For a small team shipping a marketing site with a few API routes, that is more wiring than the problem deserves, and a framework that has already made those decisions will be faster to a working deploy.

There is a second cost that the README makes explicit: the dev server runs in development mode only. That is correct behaviour, but it means the development and production paths are genuinely different code paths through the plugin. A bug that only appears when the production bundle is served will not reproduce under the dev middleware, so you need to exercise the built output before you trust it.

The repository also carries a TODO.md at the top level. The README does not describe what is in it, and this article cannot say what work is planned. The honest reading is that the project tracks its own unfinished items in the open, which is normal for a plugin of this size and worth reading before you depend on a specific behaviour.

How this differs from Next.js and Nuxt

Next.js and Nuxt are the obvious alternatives, and the difference is not performance or features. It is who owns the conventions. Both of those frameworks ship a router, a data loading model, a build pipeline and a server, and you write your application inside their structure. @fastify/vite inverts that: Fastify owns the server, Vite owns the frontend build, and the plugin is the seam between them. The README's own framing of @fastify/vue and @fastify/react as providing basic Nuxt and Next.js-like functionality is the clearest statement of the relationship. The higher-level packages imitate those frameworks; the plugin underneath does not try to.

That makes the choice a question about your existing server. If your HTTP layer is Fastify and it carries real business logic, authentication, or database access that you do not want to move, adopting a full frontend framework means either running two servers or porting that logic into the framework's server runtime. @fastify/vite avoids that port. If your server is greenfield and has no Fastify investment, the calculus flips, because you are paying the integration cost of a low-level plugin to avoid a migration you never had to make.

Releases, licence and what upgrading involves

The packages version independently. @fastify/vite reached 10.0.0 on 2026-07-30, @fastify/react is at 1.2.2 from the same day, and @fastify/vue is at 2.0.1 from 2026-07-29. The major version on the core plugin tells you the API has moved over time, and the repository uses changesets, visible in the .changeset/ directory and the @changesets/cli devDependency, so each release carries a generated changelog entry. Read the changeset for a major bump before upgrading rather than assuming the option object is stable across it.

The root package.json sets a peerDependencyRules block that ignores a missing typescript peer. That is a workspace-level convenience, not a statement about your project. If you are writing TypeScript against the plugin, you supply your own TypeScript and check the published types yourself.

Licensing is MIT, stated in the README and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained. That is the extent of what this article can say; anything about your specific obligations belongs with your legal team.

Editorial conclusion

Adopt @fastify/vite if you already run Fastify and want one Node.js process to own both the API routes and the Vite frontend, and if you are willing to wire the router integration yourself or start from the @fastify/vue and @fastify/react starters. Do not adopt it if you want a framework that decides routing, data loading and build output for you; Next.js and Nuxt make those decisions, and this project deliberately does not. Before committing, verify the peer dependency range against your installed Vite version, confirm which config keys your release expects, and check whether @fastify/vue or @fastify/react already covers the integration you were about to write by hand.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes