Introduction

In Helm, the usual way to build a ConfigMap from a file is to keep the file inside the chart and load it with .Files.Get. This is useful when your application expects a real config file such as .properties, .ini, .yaml, or similar text content. The details that matter most are where the file lives, how it is indented into YAML, and whether the file itself should be treated as a template.

Put the Source File Inside the Chart

Helm can only access files that are packaged with the chart. A common layout is to place config assets under files/.

1mychart/
2  Chart.yaml
3  values.yaml
4  files/
5    app.properties
6  templates/
7    configmap.yaml

Files in that chart tree become available through Helm's .Files object during rendering.

The Basic ConfigMap Template

If the file is plain text and does not contain Helm expressions, use .Files.Get directly.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: {{ include "mychart.fullname" . }}-config
5data:
6  app.properties: |
7{{ .Files.Get "files/app.properties" | indent 4 }}

The block scalar and indentation are important. Without the indentation step, the rendered YAML will be invalid because the file contents will not sit under the app.properties key correctly.

Render Template Expressions with tpl

Sometimes the file contains placeholders that should use chart values. In that case, .Files.Get alone is not enough because Helm will treat the contents as plain text.

Suppose files/app.properties contains:

server.port={{ .Values.app.port }}
feature.enabled={{ .Values.app.featureEnabled }}

Then the template should use tpl:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: {{ include "mychart.fullname" . }}-config
5data:
6  app.properties: |
7{{ tpl (.Files.Get "files/app.properties") . | indent 4 }}

tpl tells Helm to evaluate template expressions in the file content using the current chart context.

Bundle Multiple Files into One ConfigMap

If the application expects several files in a config directory, .Files.Glob is often convenient.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: {{ include "mychart.fullname" . }}-config
5data:
6{{- range $path, $_ := .Files.Glob "files/*.conf" }}
7  {{ base $path }}: |
8{{ $.Files.Get $path | indent 4 }}
9{{- end }}

This creates one ConfigMap key per file name, which is handy for applications that load all files in a mounted directory.

Mount the ConfigMap into the Pod

Creating the ConfigMap is only part of the job. The pod needs to see it, usually through a volume mount.

1volumes:
2  - name: app-config
3    configMap:
4      name: {{ include "mychart.fullname" . }}-config
5
6volumeMounts:
7  - name: app-config
8    mountPath: /etc/myapp

After that, the application can read /etc/myapp/app.properties or the rest of the mounted files.

Choose File-Based Config Only When It Makes Sense

Not every setting belongs in a file. If the application only needs a few scalar values, normal chart values and environment variables may be simpler. File-backed config is most useful when the application already expects a structured file or when keeping the original config format matters.

A good practical split is often:

• scalar settings in values.yaml
• larger config assets in files/
• templating only where needed

Common Pitfalls

The biggest pitfall is putting the source file outside the chart and expecting .Files.Get to find it. Helm only sees files packaged with the chart.

Another common issue is bad indentation under the YAML block scalar. That leads to broken manifests even though the file contents themselves are correct.

People also often forget to use tpl when the file contains Helm expressions, which leaves raw template text in the rendered ConfigMap.

Finally, always render the chart locally first. helm template catches many of these mistakes before they reach a cluster.

Summary

• Put config source files inside the chart, commonly under files/.
• Use .Files.Get to load a file into a ConfigMap.
• Use tpl when the file content itself contains Helm template expressions.
• Use .Files.Glob when you need to package several files together.
• Mount the resulting ConfigMap into the pod if the application reads config from disk.