Define custom environment variables¶

Version added: 1.22.0

Custom environment variables let you inject configuration without rebuilding container images. This is useful when you need to:

Align container behavior with your platform (cache size settings, time zone, locale).
Pass non-sensitive runtime flags to custom entrypoints.
Provide credentials or third-party API tokens from a Secret without baking them into images.

You can configure custom environment variables in these ways:

Supported components¶

Custom env and envFrom are supported for these components:

mongod containers: spec.replsets[].env and spec.replsets[].envFrom
mongos containers: spec.sharding.mongos.env and spec.sharding.mongos.envFrom
Log collector container: spec.logcollector.env and spec.logcollector.envFrom

Use this method when you have a small number of non-sensitive values and you want everything in a single file.

For example, you want to set a time zone to keep logs aligned across containers.

Edit the deploy/cr.yaml Custom Resource manifest

spec:
  replsets:
  - name: rs0
    size: 3
    env:
      - name: TZ
        value: "UTC"

Apply the changes:

kubectl apply -f deploy/cr.yaml -n $NAMESPACE

The Operator makes a rolling restart of your Pods.

Use this when you want to share the same variables across multiple clusters or update them without editing the Custom resource.

For example, set a custom runtime flag for mongod across all replica set pods.

Export the namespace where your cluster is running as an environment variable. Replace my-namespace with your value:
```
export NAMESPACE=my-namespace
```

Create a ConfigMap file. Let’s name it mongod-flags.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: psmdb-env-config
data:
  MONGODB_EXTRA_FLAGS: "--setParameter diagnosticDataCollectionEnabled=false"

Create the ConfigMap:

kubectl apply -f mongod-flags.yaml -n $NAMESPACE

Reference it in the Custom Resource:

spec:
  replsets:
  - name: rs0
    size: 3
    envFrom:
      - configMapRef:
          name: psmdb-env-config

Apply the changes:

kubectl apply -f deploy/cr.yaml -n $NAMESPACE

The Operator makes a rolling restart of your Pods.

Use this when you need to supply sensitive values (tokens, passwords, keys).

For example, you need to provide a token used by a custom sidecar container.

Encode your sensitive values before adding them to a Secret, as Kubernetes stores Secret data in base64-encoded form. This helps prevent accidental exposure of sensitive information in plaintext, even though it is not a secure encryption method.

To encode an API token, run:
```
echo -n "your-token" | base64
```
Copy the encoded string for use in your Secret manifest.
Export the namespace where your cluster is running as an environment variable. Replace my-namespace with your value:
```
export NAMESPACE=my-namespace
```

Create a Secret configuration file. For example, custom-sidecar.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: psmdb-env-secrets
type: Opaque
stringData:
  LOG_EXPORT_TOKEN: "your-base64-encoded-token"

Create the Secret object:

kubectl apply -f custom-sidecar.yaml -n $NAMESPACE

Reference the Secret in the Custom Resource:

spec:
  logcollector:
    enabled: true
    envFrom:
      - secretRef:
          name: psmdb-env-secrets

Apply the changes:

kubectl apply -f deploy/cr.yaml -n $NAMESPACE

The Operator makes a rolling restart of your Pods.

Last update: February 25, 2026
Created: February 25, 2026