Unprefixed `import.meta.env` variables are `undefined` on the server side

[nikolailehbrink]

I'm using React Router as a...

framework

Reproduction

https://stackblitz.com/edit/github-wcjbsndz?file=app%2Froutes%2Fhome.tsx

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 5800X 8-Core Processor
    Memory: 50.57 GB / 63.93 GB
  Binaries:
    Node: 22.14.0 - C:\nvm4w\nodejs\node.EXE
    npm: 10.9.2 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 9.5.0 - ~\AppData\Local\pnpm\pnpm.EXE
  Browsers:
    Edge: Chromium (133.0.3065.59)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    @react-router/dev: ^7.5.3 => 7.5.3
    @react-router/node: ^7.5.3 => 7.5.3
    @react-router/serve: ^7.5.3 => 7.5.3
    react-router: ^7.5.3 => 7.5.3
    vite: ^6.3.3 => 6.3.4

Used Package Manager

pnpm

Expected Behavior

import.meta.env should be available server-side in the same way it is in other Vite-powered frameworks like Astro.
For example, Astro supports this pattern:

// When import.meta.env.SSR === true
const data = await db(import.meta.env.DB_PASSWORD);

// When import.meta.env.SSR === false
const data = fetch(`${import.meta.env.PUBLIC_POKEAPI}/pokemon/squirtle`);

Reference: Astro Environment Variables Docs

I expect similar server-side access via import.meta.env in React Router v7, without falling back to process.env.

Actual Behavior

When trying to access import.meta.env.OPENAI_API_KEY inside a server-side loader() function, the value is always undefined.
However, accessing the same variable with process.env.OPENAI_API_KEY works correctly.

[timdorr]

This is just a feature of Vite.

To prevent accidentally leaking env variables to the client, only variables prefixed with VITE_ are exposed to your Vite-processed code.

Vite is the one providing the import.meta.env API and your route module is the "Vite-processed code" in question here. In production, import.meta.env may not be available on your chosen runtime (it's not in Node as of yet), so this may end up failing there. You should rely on the env system that will be available in your runtime, which will likely be process.env for most projects.

This is where the automatic code-splitting comes into play. You can use server-only APIs safely in your loader, as that will be removed from the client build and only used on the server environment.

[nikolailehbrink]

Ahh, thanks for the explanation!