Secrets Management and Environment Variables

In a React application, environment variables fall into two classes: server-side (never sent to the browser) and client-side (embedded in the JavaScript bundle). Understanding which class your variables belong to is the first step in secrets management, because client-side variables are effectively public once the bundle is deployed.

In Vite projects, only variables prefixed with VITE_ are included in the client bundle. VITE_PUBLIC_API_URL=https://api.example.com is accessible in browser code via import.meta.env.VITE_PUBLIC_API_URL. All other variables are stripped from the bundle at build time and remain server-only.

In Next.js, NEXT_PUBLIC_ prefix exposes a variable to browser JavaScript. NEXT_PUBLIC_ANALYTICS_ID=UA-123 is embedded in the client bundle. Variables without the prefix (like DATABASE_URL) are accessible only in server-side code (Server Components, API routes, Server Actions) and never sent to the browser.

A non-prefixed variable is still accessible if it is accidentally serialized. For example, if a Server Component passes its full configuration object as a prop to a Client Component, and that config includes DATABASE_URL, that secret appears in the HTML sent to the browser. Careful prop drilling and serialization auditing prevent this.

The following must never appear in the client bundle: database connection strings and passwords, third-party API secret keys (Stripe secret key, OpenAI API key), private RSA/EC keys, JWT signing secrets, internal service authentication tokens. If any of these are needed for an API call, proxy that call through a server endpoint.

The Backend for Frontend (BFF) pattern places a thin server layer between the React app and sensitive external services. The client calls /api/stripe/charge, the BFF server attaches the Stripe secret key and calls the Stripe API, and the BFF returns only the necessary response data. Secrets stay on the server permanently.

dotenv-vault encrypts your .env file and allows secure sharing and deployment across environments without checking plaintext secrets into version control. Production alternatives include HashiCorp Vault (enterprise), AWS Parameter Store (SSM), and GCP Secret Manager — all provide API-based secret retrieval at runtime rather than at build time.

CI/CD platforms (GitHub Actions, GitLab CI) provide encrypted secret storage accessible as environment variables during builds. Store secrets in GitHub Secrets, reference them in workflows as ${{ secrets.STRIPE_SECRET_KEY }}. Secrets are masked in logs and are never included in the built artifact.

Next.js and Vite support multiple .env files: .env (all environments), .env.local (local overrides, gitignored), .env.development, .env.production. The local file overrides values from the shared file, enabling developer-specific configuration without affecting other environments.

After building, audit the JavaScript bundle for accidentally exposed secrets. Run grep -r "password|secret|api_key" dist/ or use a dedicated tool like strings analysis on the built files. Some secrets, if accidentally included, are clearly identifiable by their format (UUIDs, base64 strings, or key prefixes like sk_live_).

Each environment and each service should have access only to the secrets it needs. The React client needs no secrets at all — it should only receive public identifiers. The BFF server needs only the secrets required for the APIs it calls. Development environments should use non-production API keys with limited permissions and spending caps.

What happens to a Next.js environment variable with the NEXT_PUBLIC_ prefix?

Vite uses VITE_ and Next.js uses NEXT_PUBLIC_ to expose variables to the browser bundle. All other variables are server-side only. Never include database passwords, API secret keys, or JWT signing secrets in client code. Use the BFF pattern to proxy sensitive API calls. Use dotenv-vault, AWS Parameter Store, or GitHub Secrets for production secret management. Audit built bundles for accidentally exposed secrets.