I am deploying an application to google cloud run with docker but the environment variables are undefined on production

[tahir606]

Hi guys!

I am deploying the application through docker and I have added all the required environment variables manually in google cloud run, but they aren't accessible in the deployed website. I have logged them in the front end and it is showing undefined.

Here is the docker file that I am using:

# Stage 0 - Build Frontend Assets
FROM node:14-alpine as build

WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Stage 1 - Serve Frontend Assets
FROM fholzer/nginx-brotli:v1.12.2

WORKDIR /etc/nginx
ADD nginx.conf /etc/nginx/nginx.conf

COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

FYI, the docker is working fine locally and the environments are being read as well. It is just google cloud that isn't reading them.

[yikuansun]

env variables are exposed in process.env, but Vite unfortunately uses a different system for env variables. I managed to "fix" this by reading process.env in vite.config.js:

export default defineConfig({
    define: {
        __SYSTEMENV__: JSON.stringify(process.env),
    },
    plugins: [sveltekit()],
});

At which point I could read env variables by accessing __SYSTEMENV__ from my JS files.

[yikuansun]

Figured out a better, easier way. Just use || to switch between the vite system and process.env:

import { TOKEN, } from "$env/static/private";

const handle = SetupAuth({
    token: TOKEN || process.env["TOKEN"],
});

[olamide226]

The reason this happens is timing.

Cloud Run sets environment variables when the container starts. But Vite has already built the frontend before that:

RUN npm run build

At that point Vite replaces import.meta.env.* in the browser bundle. After the static files are copied into nginx, there is no runtime process.env in the browser. So Cloud Run can have the right env vars, but the already-built JS cannot see them.

One way to solve this is to move browser config out of Vite build-time replacement and into runtime injection. REP is built for that flow:

https://github.com/RuachTech/rep

Instead of:

const apiUrl = import.meta.env.VITE_API_URL

use:

import { rep } from '@rep-protocol/sdk'

const apiUrl = rep.get('API_URL')

Then set the value in Cloud Run as:

REP_PUBLIC_API_URL=https://api.example.com
REP_PUBLIC_ENV_NAME=production

The gateway reads those env vars when the container starts and injects them into HTML as inert JSON:

<script id="__rep__" type="application/json">...</script>

For a Vite app, the Dockerfile can be simplified to let the gateway serve the static files directly:

FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json* ./
RUN npm ci
COPY . .
RUN npm run build

FROM scratch
COPY --from=ghcr.io/ruachtech/rep/gateway:latest /usr/local/bin/rep-gateway /rep-gateway
COPY --from=build /app/dist /static

EXPOSE 8080
ENTRYPOINT ["/rep-gateway", "--mode", "embedded", "--static-dir", "/static", "--port", "8080"]

Build once:

docker build -t my-vite-app:latest .

Run locally with runtime config:

docker run --rm -p 8080:8080 \
  -e REP_PUBLIC_API_URL=https://api.example.com \
  -e REP_PUBLIC_ENV_NAME=production \
  my-vite-app:latest

Deploy the same image to Cloud Run and set the same REP_PUBLIC_* variables in Cloud Run’s environment variable settings.

The important distinction is:

• VITE_* / import.meta.env.*: build-time browser config
• Cloud Run env vars: container runtime config
• REP_PUBLIC_*: runtime browser config injected when the container serves HTML

Also, be careful with define: { __SYSTEMENV__: JSON.stringify(process.env) }. It can accidentally bake too much into the browser bundle. REP uses explicit prefixes instead:

REP_PUBLIC_*     # browser-visible
REP_SENSITIVE_*  # encrypted browser-delivered values
REP_SERVER_*     # never sent to the browser

[aymenhmaidiwastaken]

Environment variables set in Google Cloud Run are available at runtime (process.env), but your Vite frontend is built at Docker build time — before the container even runs on Cloud Run.

RUN npm run build  # <-- env vars don't exist yet here

Vite replaces import.meta.env.VITE_* with hardcoded values during build. If the env vars aren't set during docker build, they're replaced with undefined.

Fix 1 — Pass env vars at build time using ARG:

FROM node:14-alpine as build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

ARG VITE_API_URL
ENV VITE_API_URL=$VITE_API_URL

RUN npm run build

Then build with:

docker build --build-arg VITE_API_URL=https://your-api.com .

Fix 2 — Use runtime config instead of Vite env vars:

Serve a /config.json from your backend or Nginx that the frontend fetches at startup:

// At app startup
const config = await fetch('/config.json').then(r => r.json());

This way the config comes from Cloud Run's runtime environment, not from build-time substitution.

Fix 3 — Use vite.config.js to read process.env:

export default defineConfig({
  define: {
    __API_URL__: JSON.stringify(process.env.API_URL),
  },
});

But this still requires the env var during build. For true runtime config on a static frontend, Fix 2 is the right approach.

[olamide226]

Agree with the diagnosis here: Cloud Run env vars arrive at container runtime, while Vite has already replaced import.meta.env.VITE_* during npm run build.

Small nuance on Fix 2: fetching /config.json at app startup is a valid runtime-config pattern, but I would not call it the best option in every case.

The tradeoffs are:

• the app now has an async config boot step before it can safely render anything that depends on config;
• modules that need config during import/init time cannot read it synchronously;
• every app has to hand-roll loading/error handling for config fetch failure;
• cache headers for /config.json are easy to get wrong, especially across CDNs;
• teams often end up dumping too much into the JSON file unless there is an explicit public/server boundary;
• there is usually no built-in validation or secret-leak guardrail.

For small apps, /config.json is often fine. For larger Docker/Kubernetes/Cloud Run deployments, I think the stronger pattern is: generate or inject a small runtime payload before the app executes, and make the public/server split explicit.

That can be done with a custom config.js, an HTML-injected JSON payload, or a gateway approach. The important part is that the runtime config is available before the app starts, instead of adding a separate startup fetch waterfall.

For example, REP uses this shape:

<script id="__rep__" type="application/json">...</script>

Then client code can read config synchronously:

import { rep } from '@rep-protocol/sdk'

const apiUrl = rep.get('API_URL')

And the runtime env is classified explicitly:

REP_PUBLIC_API_URL=https://api.example.com  # browser-visible
REP_SERVER_DB_PASSWORD=...                  # never sent to browser

So I would phrase the options as:

• build args: good when the value is meant to be baked into the image;
• /config.json: good simple runtime option, but introduces async boot/caching/security concerns;
• injected runtime payload: better when the frontend needs config synchronously and the same image must run across multiple environments.

[ltianyi992]

This is a very common Vite + Docker gotcha: Vite inlines environment variables at build time, not at runtime.

When you run npm run build inside Docker Stage 0, Vite reads your .env files from the filesystem and replaces import.meta.env.VITE_* references with literal string values in the built JS bundle. The resulting build/ folder has those values baked in — static strings in the minified code.

When Cloud Run sets environment variables on the container, those variables exist in the container process ($YOUR_VAR in bash), but the already-built nginx-served JS cannot read them — there is no Node.js process running, no runtime to call process.env.

Three solutions:

Option 1 — Pass build args to Docker (simplest for Cloud Run)

# Dockerfile
FROM node:14-alpine as build
ARG VITE_API_URL  # declare the build-time arg
ENV VITE_API_URL=$VITE_API_URL  # expose it to Vite as env var
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Build command
docker build --build-arg VITE_API_URL=https://api.example.com -t myapp .

In Cloud Run, set these as build-time values via Cloud Build substitution variables, not Cloud Run env vars.

Option 2 — Generate a runtime config file with an entrypoint script

Serve a /config.js file generated at container startup, then load it in index.html:

# docker-entrypoint.sh
#!/bin/sh
cat > /usr/share/nginx/html/config.js << EOF
window.__ENV__ = {
  VITE_API_URL: "${VITE_API_URL}",
  VITE_OTHER_VAR: "${VITE_OTHER_VAR}"
};
EOF
nginx -g "daemon off;"

<!-- index.html -->
<script src="/config.js"></script>

Then use window.__ENV__.VITE_API_URL instead of import.meta.env.VITE_API_URL in your frontend code.

Option 3 — Use a backend/SSR layer to serve the HTML with injected values, but this changes your architecture significantly.

Option 2 is the most flexible for Cloud Run since it lets runtime env vars flow through to the frontend without rebuilding the image.

[Nithwin]

This is a classic Vite + Docker timing mismatch. The root cause is straightforward once you see it.

What's actually happening

Your Dockerfile runs npm run build at image build time. At that exact moment, Vite reads your .env files from disk and replaces every import.meta.env.VITE_* reference with literal string values in the compiled JS bundle. The output in build/ is static HTML + JS with those values hardcoded.

When Google Cloud Run starts your container and sets environment variables, those variables are available to the running process (nginx or Node.js), but they're not available to the browser. The browser just downloads static files from nginx — there's no Node.js runtime in the browser, no process.env.

So Cloud Run can have the perfect env vars configured, but the already-compiled JS in your build/ folder can't see them.

Fix 1 — Pass env vars at Docker build time (simplest)

Use Docker ARG to pass variables at the moment Vite actually needs them:

FROM node:14-alpine as build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .

# Declare build args
ARG VITE_API_URL
ARG VITE_OTHER_VAR

# Expose them as env vars for Vite's build step
ENV VITE_API_URL=$VITE_API_URL
ENV VITE_OTHER_VAR=$VITE_OTHER_VAR

RUN npm run build

FROM fholzer/nginx-brotli:v1.12.2
WORKDIR /etc/nginx
ADD nginx.conf /etc/nginx/nginx.conf
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

Build it with:

docker build --build-arg VITE_API_URL=https://your-api.com -t myapp .

In Cloud Build, pass these as substitution variables, not Cloud Run runtime env vars — they need to exist at image build time, not container start time.

Fix 2 — Runtime injection via entrypoint script (same image, multiple environments)

If you want one image that can be deployed to staging and production with different configs, generate a window.__ENV__ config file at container startup:

#!/bin/sh
# docker-entrypoint.sh
cat > /usr/share/nginx/html/config.js << EOF
window.__ENV__ = {
  VITE_API_URL: "${VITE_API_URL}",
};
EOF
exec nginx -g "daemon off;"

Add it to index.html before your app bundle:

<script src="/config.js"></script>

Then in your app:

// instead of import.meta.env.VITE_API_URL
const apiUrl = window.__ENV__.VITE_API_URL;

Now Cloud Run sets VITE_API_URL as a runtime env var → entrypoint script injects it into config.js on startup → frontend reads it synchronously. One image, any environment.

Which to use?

• Build args → simpler, one image per environment, values baked in
• Entrypoint injection → one image for all environments, truly runtime config