Introduction

Helm templates can inject values into a ConfigMap just like any other Kubernetes resource. The important part is remembering that ConfigMap data values are strings and that YAML indentation matters once you start embedding multi-line files.

Most Helm ConfigMap problems are not about Helm itself. They come from three practical issues: forgetting to quote values, rendering external files without the right indentation, and losing access to the root template context inside loops.

Basic Value Injection

A simple ConfigMap template can pull values directly from values.yaml.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: {{ include "mychart.fullname" . }}
5data:
6  SERVER_NAME: {{ .Values.config.server.name | quote }}
7  SERVER_PORT: {{ .Values.config.server.port | quote }}
8  FEATURE_ENABLED: {{ .Values.config.enabled | quote }}

With values like:

1config:
2  server:
3    name: my-application
4    port: 8080
5  enabled: true

The key habit here is | quote. ConfigMap values are strings, so quoting keeps rendered YAML unambiguous.

Why quote Matters

Without quoting, booleans and numbers may be interpreted as native YAML types during rendering or validation, which is not what ConfigMap data expects.

data:
  ENABLED: {{ .Values.config.enabled | quote }}
  PORT: {{ .Values.config.server.port | quote }}

This is a small detail, but it prevents a lot of confusing “invalid type” style errors and keeps the rendered manifest predictable.

Multi-Line Config Files

ConfigMaps often contain full config files rather than only key-value flags. For that, use block scalars and pay attention to indentation.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: {{ include "mychart.fullname" . }}
5data:
6  application.properties: |
7    server.name={{ .Values.config.server.name }}
8    server.port={{ .Values.config.server.port }}
9    feature.enabled={{ .Values.config.enabled }}

If the file content comes from an external file inside the chart, .Files.Get is useful.

data:
  config.json: |-
    {{ .Files.Get "files/config.json" | nindent 4 }}

The nindent call is what keeps the embedded file aligned correctly under the block scalar.

Templating External Files With tpl

If the external file itself contains Helm expressions, use tpl so Helm evaluates them.

data:
  config.json: |-
    {{ tpl (.Files.Get "files/config.json.tpl") . | nindent 4 }}

For example:

1{
2  "serviceName": "{{ .Values.config.server.name }}",
3  "port": "{{ .Values.config.server.port }}"
4}

Without tpl, the file content is included literally and the template expressions are not rendered.

Iterating Over Values

If a ConfigMap needs repeated keys generated from a list, use range.

1data:
2  {{- range .Values.config.services }}
3  {{ .name | upper }}_URL: {{ .url | quote }}
4  {{- end }}

When you are inside a range, remember that . now refers to the current item. If you need the root context, use $.

{{- range .Values.config.services }}
  {{ .name }}: {{ $.Values.global.environment | quote }}
{{- end }}

That is one of the most common Helm templating gotchas.

Common Pitfalls

A common mistake is forgetting | quote on values that look numeric or boolean. ConfigMap data should be rendered as strings.

Another issue is using .Files.Get for a file that also needs template evaluation. In that case, tpl is required in addition to file loading.

Developers also often use indent when nindent was needed, which breaks YAML alignment in block content.

Finally, when a template is inside range, root lookups like .Values.global... stop working unless you switch to $ explicitly.

Summary

• Inject Helm variables into ConfigMaps the same way you do in other templates.
• Quote ConfigMap values so they remain strings.
• Use block scalars plus nindent for multi-line content.
• Use .Files.Get for external files and tpl when those files themselves contain Helm expressions.
• Inside range, use $ when you need access to the root chart context.