How to host backend API within Vite configured for React

[adam-nielsen]

I have Vite working with a React frontend. I would like the same Vite instance to also serve the NodeJS backend.

I have done this by importing my backend code in vite.config.ts and then using a custom plugin to ultimately call server.middlewares.use() so that my API code gets called to handle the /api URL.

This all works fine, but I can't use import.meta.env in my backend code, HMR is unreliable, and typos in my backend code cause Vite to terminate. Reading up on it, the import.meta.env issue seems to be because Vite doesn't load the .env file until after it has finished processing the config, so since I'm importing code in vite.config.ts it's running before import.meta.env is available. This suggests that importing application code in the Vite config file is not the correct way to have it handle new URLs.

So my question is what is the best way to have my Node backend API run in the same Vite instance as the React frontend, such that the backend code is treated the same as the frontend (i.e. import.meta.env is available, crashes don't terminate Vite, etc.)

[shreyanshjain1]

I dont think importing your actual backend app into vite.config.ts is the right shape for this.

From what you described, it works, but it also explains all the weird side effects:

• backend code runs too early
• import.meta.env is awkward
• backend crashes can take down Vite itself
• HMR gets unreliable

So I’d probly treat this as:

• Vite dev server = frontend tooling/dev server
• Node backend = its own server/process
• connect them in dev with a proxy instead of trying to make Vite “be” the backend runtime

So the cleaner setup is usually:

1. run your backend separately (Express/Fastify/etc.)
2. let Vite serve the React app
3. proxy /api from Vite to the backend server

That way:

• your backend gets its own normal Node lifecycle
• env loading can be handled in the backend the normal way
• backend crashes dont kill the Vite process
• frontend HMR stays predictable

Trying to make backend application code live inside the Vite config ends up mixing 2 different responsibilities:

• configuring the dev server
• actually running your server app

If your goal is “same port for the browser”, the proxy still gives you that developer experience without forcing both runtimes into the same execution path.

So my short answer would be:

• yes, your current approach is a sign that vite.config.ts is being stretched too far
• the better pattern is usually separate backend process + Vite proxy
• not “load the whole backend app inside the Vite config”

If you really want a single command to start both, I’d still do it as two processes launched together, not one process with the backend embedded into Vite.

If this helps, feel free to mark it as the answer so others can find it faster.

[adam-nielsen]

Yeah the problem is that this requires you do manually do everything in the backend, like setting up and maintaining hot reloading yourself. The idea behind using Vite is that you get all that for free, so it greatly simplifies the set up and maintenance of the backend.

[chrisjcthomas]

The Vite docs point toward keeping these as separate responsibilities:

• Vite dev server for frontend tooling/HMR
• your Node backend as its own server/process
• server.proxy to make /api feel same-origin during development

Vite already has first-class support for this pattern via:

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
      },
    },
  },
})

That matches the problems you're seeing with importing backend runtime code into vite.config.ts:

• it runs too early
• import.meta.env isn't the same experience
• backend crashes can take down Vite
• HMR becomes unreliable

So I don't think the "best" shape is to make one Vite instance be your backend runtime. The cleaner setup is:

1. run the backend as its own Node process
2. run Vite for the React app
3. proxy /api through Vite in dev

If you want a single command, I'd still orchestrate two processes rather than embedding the backend inside the Vite config.

[adam-nielsen]

Yeah this is what I ended up doing. Vite still isn't perfect for backend instances but it's still better than doing everything manually. We just have to start two instances (frontend and backend) and remember to restart the backend instance after code changes as hot reloading only works sometimes, but it's good enough to keep working for now.