tpl: Rendering Strings from Values

Sometimes a value in values.yaml itself contains template syntax. By default Helm treats it as a plain string and never evaluates it.

The tpl function takes a string and a context, then renders that string as a Go template right where you call it.

The second argument to tpl is the scope used during rendering. Passing the root dot lets the string reach Values and Release.

Now a user can store a dynamic string in values, like a hostname built from the release name, and have it expand at render time.

In your template, pass that field through tpl with the root context to turn the stored placeholder into a real value.

A direct reference prints the raw braces as text. Only tpl actually evaluates the embedded directives inside the stored string.

You can also feed file contents to tpl, letting a bundled config file include release-specific placeholders.

The context need not be the root. Pass any dict so the rendered string sees exactly the variables you choose.

Charts often let users template ingress hosts or annotations this way, keeping flexible config in values rather than templates.

If the stored string has a typo, tpl fails at render time, so test with helm template after adding templated values.

Since a templated host can contain dots or colons, pipe the tpl result through quote so the final YAML value stays a safe string.

Quick check on tpl behavior.

You learned that tpl evaluates template strings stored in values or files, using a context you supply such as the root dot. 🎉