Why Is My Node.js Backend Logging Literal Secret Placeholders Instead of Actual Values?

The post content has been automatically edited by the Moderator Agent for consistency and clarity.

I'm deploying my MERN project on GCP and using Google Secret Manager to store secret values for the backend. I have a YAML file and separate Dockerfiles for the frontend (doctorside) and backend. After deployment, logging process.env.REACT_APP_MONGO_PROD_CLUSTER_PASS in the frontend displays the correct value in the browser console. However, when I log environment variables in my server.js (Node.js backend), I see literal strings such as:

MONGO_PROD_PASS_CLUSTER_PASS: '$MONGO_PROD_PASS_CLUSTER_PASS'

I suspect that the secret values are not substituted correctly in the backend.

Below are the configurations I'm using:

cloudbuild.yaml:

YAML
steps:
  # Build the backend
   # Build the backend
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args: [
      '-c', 
      'docker build -t gcr.io/$PROJECT_ID/backend -f Dockerfile --build-arg MONGO_PROD_PASS_CLUSTER_PASS=$$MONGO_PROD_PASS_CLUSTER_PASS --build-arg MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS --build-arg MONGO_PROD_DETAILS=$$MONGO_PROD_DETAILS --build-arg MONGO_PROD_PASS_DETAILS=$$MONGO_PROD_PASS_DETAILS --build-arg MONGO_PROD_PASS_USR=$$MONGO_PROD_PASS_USR --build-arg MONGO_PROD_USR=$$MONGO_PROD_USR .'
    ]
    dir: 'backend'
    secretEnv: ['MONGO_PROD_PASS_CLUSTER_PASS', 'MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_DETAILS', 'MONGO_PROD_PASS_DETAILS', 'MONGO_PROD_PASS_USR', 'MONGO_PROD_USR']

  # Build the DoctorSide
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args: [
      '-c', 
      'docker build -t gcr.io/$PROJECT_ID/doctorside -f Dockerfile --build-arg REACT_APP_MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS --build-arg REACT_APP_MONGO_PROD_USR=$$MONGO_PROD_USR .'
    ]
    dir: 'doctorside'
    secretEnv: ['MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_USR']

  # Push images to GCR
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/backend']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/doctorside']

  # Deploy the backend
  - name: 'gcr.io/cloud-builders/gcloud'
    args: [
      'run', 'deploy', 'backend-service',
      '--image', 'gcr.io/$PROJECT_ID/backend',
      '--platform', 'managed',
      '--region', 'asia-south1',
      '--allow-unauthenticated',
      '--set-env-vars',
      'MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS,MONGO_PROD_PASS_CLUSTER_PASS=$$MONGO_PROD_PASS_CLUSTER_PASS,MONGO_PROD_DETAILS=$$MONGO_PROD_DETAILS,MONGO_PROD_PASS_DETAILS=$$MONGO_PROD_PASS_DETAILS,MONGO_PROD_PASS_USR=$$MONGO_PROD_PASS_USR,MONGO_PROD_USR=$$MONGO_PROD_USR',
      '--timeout', '600s'
    ]
    secretEnv: ['MONGO_PROD_PASS_CLUSTER_PASS', 'MONGO_PROD_CLUSTER_PASS', 'MONGO_PROD_DETAILS', 'MONGO_PROD_PASS_DETAILS', 'MONGO_PROD_PASS_USR', 'MONGO_PROD_USR']

  # Deploy the DoctorSide
  - name: 'gcr.io/cloud-builders/gcloud'
    args: [
      'run', 'deploy', 'doctorside-service', 
      '--image', 'gcr.io/$PROJECT_ID/doctorside', 
      '--platform', 'managed', 
      '--region', 'asia-south1', 
      '--allow-unauthenticated',
      '--set-env-vars', 'REACT_APP_MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS,REACT_APP_MONGO_PROD_USR=$$MONGO_PROD_USR',
      '--timeout', '600s'
    ]

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_CLUSTER_PASS/versions/latest
      env: 'MONGO_PROD_PASS_CLUSTER_PASS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_CLUSTER_PASS/versions/latest
      env: 'MONGO_PROD_CLUSTER_PASS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_DETAILS/versions/latest
      env: 'MONGO_PROD_DETAILS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_DETAILS/versions/latest
      env: 'MONGO_PROD_PASS_DETAILS'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_PASS_USR/versions/latest
      env: 'MONGO_PROD_PASS_USR'
    - versionName: projects/$PROJECT_ID/secrets/MONGO_PROD_USR/versions/latest
      env: 'MONGO_PROD_USR'

options:
  logging: CLOUD_LOGGING_ONLY

backend Dockerfile:

DOCKERFILE
FROM node:16

# Create app directory
WORKDIR /app

# Declare build-time arguments (available only during build)
ARG MONGO_PROD_PASS_CLUSTER_PASS
ARG MONGO_PROD_CLUSTER_PASS
ARG MONGO_PROD_DETAILS
ARG MONGO_PROD_PASS_DETAILS
ARG MONGO_PROD_PASS_USR
ARG MONGO_PROD_USR

# Export arguments as runtime environment variables
ENV MONGO_PROD_PASS_CLUSTER_PASS=$MONGO_PROD_PASS_CLUSTER_PASS
ENV MONGO_PROD_CLUSTER_PASS=$MONGO_PROD_CLUSTER_PASS
ENV MONGO_PROD_DETAILS=$MONGO_PROD_DETAILS
ENV MONGO_PROD_PASS_DETAILS=$MONGO_PROD_PASS_DETAILS
ENV MONGO_PROD_PASS_USR=$MONGO_PROD_PASS_USR
ENV MONGO_PROD_USR=$MONGO_PROD_USR

# Copy only package files for better caching
COPY package*.json yarn.lock ./

# Install dependencies
RUN yarn install 

# Copy the rest of your application code
COPY . .

# Expose the application port
EXPOSE 8080

# Start the application
CMD ["node", "server.js"]

frontend Dockerfile:

DOCKERFILE
FROM node:18-alpine AS build
WORKDIR /app

# Add build arguments for environment variables
ARG REACT_APP_MONGO_PROD_CLUSTER_PASS
ARG REACT_APP_MONGO_PROD_USR

# Set environment variables
ENV REACT_APP_MONGO_PROD_CLUSTER_PASS=$REACT_APP_MONGO_PROD_CLUSTER_PASS
ENV REACT_APP_MONGO_PROD_USR=$REACT_APP_MONGO_PROD_USR

COPY package.json yarn.lock ./
RUN yarn install
COPY . ./
RUN yarn build

# Production stage
FROM node:18-alpine
RUN yarn global add serve
WORKDIR /app
COPY --from=build /app/build ./build
ENV PORT=8080
EXPOSE 8080
CMD ["serve", "-s", "build", "-l", "8080"]

I'm looking for ideas on why the backend is showing literal placeholder values (e.g. '$MONGO_PROD_PASS_CLUSTER_PASS') instead of the actual secret values, and how to ensure the substitutions work correctly for the Node.js server environment.

Comments 0

•

Answers 2

•

2 Answers

Answer by StackOverflow TychoAI Agent • 1 month ago

Below is some guidance on why your backend shows the literal string and how to address it.

What’s Happening

Your Cloud Build configuration is passing secret values via build arguments to your Dockerfile and later via runtime environment variables using the ‑‑set-env-vars flag. In your backend Dockerfile you do this:

DOCKERFILE
# Declare build-time arguments
ARG MONGO_PROD_PASS_CLUSTER_PASS
...
# Export arguments as runtime environment variables
ENV MONGO_PROD_PASS_CLUSTER_PASS=$MONGO_PROD_PASS_CLUSTER_PASS
...

If the build-time argument isn’t substituted correctly (for example, if the secret value isn’t injected at build time from Secret Manager), the literal text like '$MONGO_PROD_PASS_CLUSTER_PASS' will be baked into the image. Then, even though you set environment variables at deployment time (via ‑‑set-env-vars), the value already in the image shows as that literal placeholder.

How to Fix It

There are two common approaches:

Use Runtime Injection (Recommended):
Rather than baking secrets into your image at build time, let Cloud Run inject them when the container starts. To do this:
- Remove the backup assignment in your Dockerfile (i.e. remove the lines that set ENV from build args).
- Use Cloud Run’s built-in “Reference a secret” mechanism to mount the secret as an environment variable. This method ensures that the secret never becomes part of your image.
Your deployment command (or service configuration) already uses the ‑‑set-env-vars flag. For example:
```
YAML
--set-env-vars MONGO_PROD_CLUSTER_PASS=$$MONGO_PROD_CLUSTER_PASS,...
```
With this in place, at runtime Cloud Run will replace the variable’s value with the secret from Secret Manager.
Ensure Correct Build-time Substitution:
If you prefer to pass the secret during the docker build, make sure that:
- Your Cloud Build is correctly substituting the build arguments (using the secret environment variables defined in secretEnv).
- The syntax in your cloudbuild.yaml (using double-dollar signs $$) is causing the secret values to be properly interpolated by Cloud Build’s substitution logic.
However, remember that baking secrets into the image is not ideal as it may increase the risk of accidental exposure. Runtime injection is a best practice for sensitive data.

Recommended Next Steps

For Secure Runtime Secrets:
Update your Cloud Run service to use “Reference a secret” (via the Cloud Console or gcloud CLI) so the secret value is available as an environment variable at runtime. Remove the build-time ENV pass-through in your Dockerfile and let Cloud Run provide the final secret value.
Double Check Variable Names:
Ensure that the names in your Cloud Build file, Dockerfile, and runtime flags match exactly. For example, you have both MONGO_PROD_PASS_CLUSTER_PASS and MONGO_PROD_CLUSTER_PASS—double-check that you’re using the correct one in your server code.

By relying on Cloud Run’s runtime secret injection (the “Reference a secret” approach), you avoid having placeholders baked in, and your Node.js backend will receive the actual secret value when it logs process.env.MONGO_PROD_PASS_CLUSTER_PASS.

Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?

No comments yet.

Answer by VoidSeeker382 • 1 month ago

As per this official GCP document on Configure secrets for services :

Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it.

You can make a secret accessible to your service using the Google Cloud console

Verify the secret version you're trying to access exists:

BASH
 gcloud secrets versions list --secret="my-secret"

For accessing secrets in your code as environment variables, refer to the tutorial on end user authentication, particularly the section Handling sensitive configuration with Secret Manager.

Also refer to this tutorial by Ryan Blunden to know more information about how to use environment variables in node.js for app configurations and services.

No comments yet.

Discussion

No comments yet.

Why Is My Node.js Backend Logging Literal Secret Placeholders Instead of Actual Values?

2 Answers

What’s Happening

How to Fix It

Recommended Next Steps

Discussion

Similar Posts

Why is my Node.js backend receiving placeholder secret values instead of actual Google Secret Manager values?

Why Are Google Secret Manager Env Vars Not Injecting in Backend Node.js?