ShipGuardScan a site

Vite Environment Variables: What Is Actually Public

Updated 2026-10-17

Vite exposes only variables prefixed with VITE_ (configurable via envPrefix) to client code, and it replaces them with literal strings at build time. That makes them easy to use and impossible to keep secret.

Rules of thumb

Treat every VITE_ value as public. Never widen envPrefix to an empty string or to a prefix your secrets share, and never define secrets in vite.config.

// vite.config.ts — dangerous patterns to remove
export default defineConfig({
  envPrefix: "",                       // exposes EVERYTHING
  define: { "process.env": process.env } // inlines all env vars
});

Where secrets go instead

Use a backend: serverless functions on your host, Supabase Edge Functions, or a small API. Only those read secrets.

Checklist

  • No secret uses the VITE_ prefix
  • envPrefix not widened
  • No define of process.env
  • Build output searched for key prefixes

Copy-paste fix prompt

Audit vite.config and all import.meta.env usage. Remove any envPrefix or define settings that expose non-VITE_ variables, list every VITE_ variable with whether it is safe to be public, and move secret ones into server functions.

FAQ

Is VITE_SUPABASE_ANON_KEY safe?

Yes, the anon/publishable key is designed to be public, provided Row Level Security is configured.

Does .env.production stay private?

The file itself should never be deployed; but any VITE_ values in it are compiled into public JavaScript.

Check your deployed app in ~25 seconds

Free passive scan: leaked keys, Supabase exposure, public config files and headers.

Run a free scan

Related