What's the difference between literals mode and file-content mode?

Literals mode writes each key/value pair as its own line under data, exactly like `kubectl create configmap --from-literal`. File-content mode writes a single key (the file name) whose value is a multi-line YAML block scalar containing the whole file's text, exactly like `kubectl create configmap --from-file`, which is what you want when a container expects to mount a ConfigMap key as a config file.

What does the immutable flag do?

Setting immutable: true tells the API server to reject any further updates to this ConfigMap's data or binaryData. Kubernetes recommends this for ConfigMaps that shouldn't change, since it also removes the kubelet's need to watch the object for changes, reducing load on the API server at scale.

Can a ConfigMap hold binary data?

Kubernetes ConfigMaps support a separate binaryData field for base64-encoded binary content, but this generator only produces the text-based data field, since the vast majority of ConfigMap use cases (environment values, config files, scripts) are plain text.

How do I actually use a file-content ConfigMap in a Pod?

Mount it as a volume: reference the ConfigMap under spec.volumes, then mount that volume into the container at the path where the config file should appear; the ConfigMap's key becomes the file name inside the mounted directory.

Kubernetes ConfigMap Generator - Build ConfigMap YAML

Overview

Introduction

ConfigMaps are simple in concept but the YAML gets fiddly the moment you need to embed a whole file's contents, since that means getting a YAML block scalar's indentation exactly right.

This tool generates a ConfigMap manifest from either repeatable key/value pairs or a single pasted file's contents, handling the block-scalar indentation for you, entirely client-side.

What Is Kubernetes ConfigMap YAML Generator?

A Kubernetes ConfigMap YAML generator supporting the two most common creation patterns: multiple literal key/value entries, or one file's full text content under a single key.

It also supports the immutable flag, which locks the ConfigMap's data against further changes once created.

How Kubernetes ConfigMap YAML Generator Works

In literals mode, every key/value row you add becomes one line under the data map, quoted only when the value would otherwise be ambiguous YAML (for example, a value that looks like a number or starts with a special character).

In file-content mode, the file name becomes the data key and its value is written as a YAML literal block scalar (a `|` block), with every line of your pasted content indented consistently beneath it, preserving line breaks exactly as written.

When immutable is enabled, an immutable: true line is appended at the top level of the manifest, alongside data.

When To Use Kubernetes ConfigMap YAML Generator

Use literals mode for simple key/value application configuration, like feature flags or a handful of environment values you'll consume via envFrom or individual env entries.

Use file-content mode when a container expects an entire config file (nginx.conf, application.properties, a JSON config) mounted at a specific path.

Reach for immutable once a ConfigMap's values are finalized and won't change without a new ConfigMap name, to get the API server load benefit Kubernetes documents.

Often used alongside Kubernetes Secret YAML Generator, Kubernetes Deployment YAML Generator and Kubernetes Namespace YAML Generator.

Features

Advantages

Handles YAML block-scalar indentation for pasted file content automatically, a common source of hand-written ConfigMap bugs.
Supports both the literal key/value and whole-file creation patterns in one tool, matching kubectl's two --from-literal/--from-file conventions.
Runs entirely in your browser; the file content you paste is never uploaded anywhere.

Limitations

Only produces a single file entry in file-content mode; a ConfigMap with multiple mounted files needs additional data keys added manually.
Doesn't support binaryData for binary file content.
Doesn't validate that referencing Deployments or volumes actually consume the generated keys correctly.

Examples

A literals-mode ConfigMap with two configuration values

Input

name: app-config, literals: [LOG_LEVEL=debug, FEATURE_X=enabled]

Output

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: debug
  FEATURE_X: enabled

Each literal becomes its own data key, exactly matching kubectl create configmap --from-literal output.

Best Practices & Notes

Best Practices

Keep secrets out of ConfigMaps entirely, even though nothing technically prevents it; use the Secret Generator for any sensitive value.
Use immutable: true for ConfigMaps that back a Deployment's environment variables, so a change always means a new ConfigMap (and a clear rollout), not a silent in-place update.
Prefer one ConfigMap per logical concern (per file, per service) rather than one giant ConfigMap shared across unrelated workloads.

Developer Notes

File-content mode implements the YAML literal block scalar (`|`) manually: the raw text is split on newlines, each line re-indented by four spaces relative to the data key, and blank lines are emitted as empty strings rather than padded with trailing spaces, keeping the block scalar's content byte-for-byte faithful to the pasted input. Literal mode reuses the same conditional-quoting logic as the other generators in this category, quoting a scalar only when leaving it bare would change its parsed type or meaning.

Kubernetes ConfigMap YAML Generator Use Cases

Externalizing environment-style configuration values for a Deployment via literals mode
Mounting a full configuration file (nginx.conf, log4j.properties, a JSON settings file) into a container via file-content mode
Locking a finalized configuration against accidental in-place edits with the immutable flag

Common Mistakes

Editing a mutable ConfigMap's values in place and expecting running Pods to pick up the change instantly; most consumption patterns (env vars, some volume mount configurations) don't hot-reload without a Pod restart.
Mismatching the file name used as the data key against the file name a container's config-loading logic actually expects to find when volume-mounted.
Putting sensitive values (API keys, passwords) into a ConfigMap instead of a Secret, since ConfigMap data is stored and displayed as plain text.

Tips

Use the Kubernetes Secret Generator instead for anything sensitive; the two objects are consumed by Pods the same way but stored and treated very differently by Kubernetes.

Kubernetes ConfigMap YAML Generator