Skip to main content

ConfigMaps

ConfigMaps store non-sensitive configuration data as key-value pairs. They're useful for feature flags, configuration files, and any settings you want to manage separately from your container image.

Defining a ConfigMap​

configmaps:
  - name: app-config
    data:
      FEATURE_FLAG_NEW_UI: 'true'
      LOG_LEVEL: info

Each ConfigMap needs a name and at least one entry in data. Keys must be RFC 1123 compliant.

Using ConfigMaps​

As Environment Variables​

Inject all keys from a ConfigMap into a service or job with envFrom:

configmaps:
  - name: app-config
    data:
      FEATURE_FLAG_NEW_UI: 'true'
      LOG_LEVEL: info

services:
  - name: api
    image_from_build: api-build
    envFrom:
      - configMapRef:
          name: app-config

Each key in the ConfigMap becomes an environment variable in the container.

You can also reference individual keys with valueFrom:

services:
  - name: api
    image_from_build: api-build
    env:
      - name: LOG_LEVEL
        valueFrom:
          configMapKeyRef:
            name: app-config
            key: LOG_LEVEL

As Mounted Files​

Mount a ConfigMap as files in your pod using a shared volume:

configmaps:
  - name: nginx-conf
    data:
      nginx.conf: |
        server {
          listen 80;
          location / {
            proxy_pass http://api:3000;
          }
        }

shared_volumes:
  - name: config-vol
    type: configmap
    source: nginx-conf

services:
  - name: nginx
    image: nginx:1.27-alpine
    volumes:
      - name: config-mount
        mount_path: /etc/nginx/conf.d
        claim: config-vol

ConfigMaps vs. Secrets​

Use ConfigMaps for non-sensitive values like feature flags and configuration settings. For credentials and sensitive data, use secrets instead.

See the Secrets and Parameters guide for a full classification matrix.

Schema Reference​

See the ConfigMap schema for the full configuration reference.