Introduction

A React application in the browser cannot directly read environment variables from a Kubernetes container at runtime. Those variables belong to the server-side process inside the pod, while the React code runs later in the user's browser, so you have to inject configuration into something the browser can actually load.

Why Direct Access Does Not Exist

This is the architectural boundary that matters:

• Kubernetes env vars exist inside the container process
• React frontend code is bundled into static JavaScript
• the browser only sees static files and HTTP responses

So if you set an environment variable on a pod, the browser does not magically gain access to it. The value must be copied into the built bundle, a runtime config file, or an API response.

Option 1: Build-Time Injection

If the value is known when the image is built, inject it during the frontend build. A typical Dockerfile for a React app can pass build arguments into the build process.

1FROM node:20 AS build
2WORKDIR /app
3COPY package*.json ./
4RUN npm install
5COPY . .
6
7ARG REACT_APP_API_URL
8ENV REACT_APP_API_URL=$REACT_APP_API_URL
9
10RUN npm run build

Then build the image with the value:

docker build \
  --build-arg REACT_APP_API_URL=https://api.example.com \
  -t my-react-app .

Inside the app:

const apiUrl = process.env.REACT_APP_API_URL;
console.log(apiUrl);

This is simple, but the value is baked into the client bundle. That makes it appropriate only for public, non-secret configuration.

Option 2: Runtime Config File

If you want one image that can be reused across environments, a runtime config file is often the better approach. The container starts, reads its env vars, generates a small JavaScript file, and serves it alongside the static frontend.

1#!/usr/bin/env sh
2cat <<EOF >/usr/share/nginx/html/config.js
3window.APP_CONFIG = {
4  API_URL: "${API_URL}",
5  APP_ENV: "${APP_ENV}"
6};
7EOF
8
9exec nginx -g 'daemon off;'

Kubernetes can set the container env vars in the Deployment:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: frontend
5spec:
6  template:
7    spec:
8      containers:
9        - name: frontend
10          image: my-react-app:latest
11          env:
12            - name: API_URL
13              value: https://api.example.com
14            - name: APP_ENV
15              value: production

Then load config.js from index.html and read it in React:

const apiUrl = window.APP_CONFIG.API_URL;

This pattern keeps the image reusable while still making configuration visible to the browser.

ConfigMaps and Secrets

For non-secret values, a ConfigMap is a good source for those env vars or config-file contents. For secret values, the frontend should usually not receive them at all. If the browser can read a value, the user can inspect it too.

That is why API keys, database passwords, or private signing material do not belong in client-side React configuration, whether it comes from build args, ConfigMaps, or runtime files.

Option 3: Backend Endpoint

Sometimes the best answer is not environment variables in the frontend at all. If the configuration is dynamic, sensitive, or user-specific, expose it through a backend endpoint and let the React app fetch it after load.

That shifts the logic to a trusted server process and avoids treating frontend assets like a secret store.

Common Pitfalls

Expecting browser JavaScript to read Kubernetes pod environment variables directly is the core misunderstanding behind this question.

Putting secrets into a React bundle or runtime config file makes them visible to anyone using the app.

Rebuilding the frontend image for every environment can be wasteful when a runtime config file would let one image serve staging and production.

Forgetting framework-specific public prefixes can make build-time variables appear missing even though the build completed successfully.

Treating frontend configuration and backend secret management as the same problem leads to insecure designs.

Summary

• A React app in the browser cannot directly access Kubernetes container env vars.
• Use build-time injection for stable public values known during image creation.
• Use a runtime config file when one image should work across several environments.
• Use ConfigMaps for non-secret runtime values, not for browser-visible secrets.
• Move sensitive or dynamic configuration behind a backend API instead of exposing it to the client bundle.