Discovering the Power of templatefile() in Terraform: A DevOps Engineer’s Perspective

One of the things I love about working in DevOps is those moments when you stumble upon a feature that makes you think: “Wow, this is going to make my life so much easier.” Recently, I had that exact moment with Terraform’s templatefile() function.

Now, if you’ve been around long enough in infrastructure automation, chances are you’ve worked with Jinja2 before. Maybe in Ansible playbooks, maybe in Python projects, maybe even in Helm alternatives. Jinja2 is powerful — no doubt about it. But when I first tried Terraform’s templatefile(), I realized that Terraform deliberately chose a different path, and for good reason. Let me walk you through why this little function feels like a hidden gem in Terraform’s toolbox.

What is templatefile() Anyway?

At its core, templatefile() lets you render external template files with variables from Terraform. You give it a path to a .tpl file and a map of variables, and it spits out clean, ready-to-use content.

templatefile(path, vars)

• path: path to your template file (userdata.tpl, config.yaml.tpl, etc.)
• vars: a map of values you want injected into that file

The template itself uses a familiar syntax:

• ${variable} → variable interpolation
• %{ if ... } / %{ for ... } → conditionals and loops

That’s it. Simple, readable, predictable.

And yet… surprisingly powerful when you realize where it fits in Terraform’s ecosystem.

The First “Aha!” Moment: User Data

Think about provisioning an EC2 instance. Usually, you have to jam a user data script inline inside your Terraform code. That’s not fun — multi-line shell scripts in HCL are messy.

Enter templatefile().

#!/bin/bash
echo "Hello, ${name}" > /var/www/html/index.html
apt-get update -y
apt-get install -y nginx
systemctl start nginx

That’s a userdata.tpl file. Clean, separate, and version-controlled.

Now in Terraform:

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  user_data = templatefile("${path.module}/userdata.tpl", {
    name = "Ashkan"
  })
}

Suddenly your Terraform code is tidy, and your script is modular. You can reuse it across multiple environments just by swapping variables.

It feels like separating frontend from backend in software engineering — clear boundaries, cleaner thinking.

The Second “Aha!” Moment: Kubernetes YAML

Now let’s talk Kubernetes. Terraform can manage Kubernetes resources, but often you already have YAML manifests you want to reuse. Manually converting them into Terraform HCL? Painful.

Instead, drop your YAML into a template:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ${app_name}
spec:
  replicas: ${replicas}
  template:
    spec:
      containers:
      - name: ${app_name}
        image: ${image}:${tag}

Feed it into Terraform with templatefile():

resource "kubernetes_manifest" "app" {
  manifest = yamldecode(templatefile("${path.module}/deployment.tpl", {
    app_name = "myapp"
    replicas = 3
    image    = "nginx"
    tag      = "1.27.0"
  }))
}

Boom. Terraform now manages your Kubernetes resources dynamically, while you still write manifests in the YAML style your team already knows. This was the moment I thought: “Why didn’t I do this earlier?”

Comparing It with Jinja2: A Familiar but Different Experience

As someone who’s used Jinja2 extensively in Ansible, my first instinct was: “This is nice, but is it as powerful as Jinja2?”

Here’s the thing: it’s not supposed to be.

Jinja2 is almost a programming language in itself. You can write complex conditionals, loops, filters, macros, even inherit from other templates. That power is fantastic when you’re building complex Ansible playbooks or dynamic configs in Python apps.

But with power comes complexity. I’ve seen Jinja2 templates that are so logic-heavy they become unreadable — debugging them feels like spelunking through someone else’s spaghetti brain.

Terraform’s templatefile(), on the other hand, is deliberately minimalist:

At first, I thought this was a limitation. But then it hit me: Terraform doesn’t need that kind of power.

Terraform wants your infrastructure definitions to be predictable, reproducible, and transparent. Too much logic in templates would break that. templatefile() is just enough to be flexible without opening the door to chaos.

Side-by-Side Example: Jinja2 vs Terraform 

templatefile()

Let’s say we want to deploy a Kubernetes Deployment with configurable replicas, image, and app name.

Here’s what it looks like in Jinja2 (think Ansible):

deployment.yaml.j2 (Jinja2):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ app_name }}
spec:
  replicas: {{ replicas }}
  selector:
    matchLabels:
      app: {{ app_name }}
  template:
    metadata:
      labels:
        app: {{ app_name }}
    spec:
      containers:
      - name: {{ app_name }}
        image: {{ image }}:{{ tag }}
        {% if env is defined %}
        env:
        {% for key, value in env.items() %}
        - name: {{ key }}
          value: "{{ value }}"
        {% endfor %}
        {% endif %}

And then in Ansible, you’d render it like:

- name: Render Kubernetes deployment
  template:
    src: deployment.yaml.j2
    dest: /tmp/deployment.yaml
  vars:
    app_name: "myapp"
    replicas: 3
    image: "nginx"
    tag: "1.27.0"
    env:
      LOG_LEVEL: debug
      FEATURE_FLAG: enabled

👉 Super powerful — you get loops, conditionals, and filters. But it also means templates can get logic-heavy and messyreally fast.

Now, the same thing in Terraform with templatefile():

deployment.tpl (Terraform template):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ${app_name}
spec:
  replicas: ${replicas}
  selector:
    matchLabels:
      app: ${app_name}
  template:
    metadata:
      labels:
        app: ${app_name}
    spec:
      containers:
      - name: ${app_name}
        image: ${image}:${tag}
%{ if length(env) > 0 }
        env:
%{ for key, value in env }
        - name: ${key}
          value: "${value}"
%{ endfor }
%{ endif }

And in Terraform HCL:

resource "kubernetes_manifest" "app" {
  manifest = yamldecode(templatefile("${path.module}/deployment.tpl", {
    app_name = "myapp"
    replicas = 3
    image    = "nginx"
    tag      = "1.27.0"
    env      = {
      LOG_LEVEL    = "debug"
      FEATURE_FLAG = "enabled"
    }
  }))
}

👉 Notice how similar they look, but also how Terraform keeps it minimal:

• No filters, no macros, no nesting complexity.
• Just enough logic (if, for) to get the job done.
• Tied directly into Terraform’s lifecycle — meaning if you change a var, Terraform knows exactly what to update in your infra.

The Takeaway from the Comparison

• With Jinja2, you get maximum power, but that power can turn your templates into mini-programs (and debugging into nightmares).
• With Terraform templatefile(), you get just enough power, and you stay in the mindset of infrastructure-as-code — simple, declarative, predictable.

And that’s exactly the design philosophy:

• Jinja2 is a general-purpose templating engine.
• templatefile() is an IaC-focused templating helper.

Why This Matters for Us as DevOps Engineers

As DevOps engineers, we live in a world of interfaces: tools talking to tools, systems talking to systems. Often we need a bit of glue — a config file here, a YAML manifest there, a startup script on the side.

• With Jinja2, we reach for it when we need complex config generation, like dynamic Ansible playbooks or web frameworks.
• With Terraform templatefile(), we use it when we want just enough templating to cleanly bridge between infrastructure and the configs/scripts it needs.

The beauty is in its simplicity. It doesn’t try to be everything — it tries to be exactly what Terraform needs.

And honestly, that’s why I love it. It feels like Terraform saying: “Hey, we know you’ll need templates, but we’ll keep it sane for you.”

Closing Thought

When I saw the same Kubernetes Deployment written in both, it clicked:

• Jinja2 is like a Swiss army knife with every possible blade.
• templatefile() is like the one screwdriver you always need right next to your Terraform code.

Both have their place, but knowing when to reach for which tool keeps your automation clean, maintainable, and fun to work with.

🔥 That’s why discovering templatefile() felt like a small revolution in my Terraform workflows. It’s not about doing everything, it’s about doing the right thing in the right context.