How to Use Terraform Local_File [Examples]

In this article, you’ll learn how the local_file resource works and explore some common examples.

What is the local_file in Terraform?

The local_file resource is part of the HashiCorp Local provider (hashicorp/local). It lets Terraform write files directly to the filesystem where Terraform runs. Unlike most Terraform resources, which manage cloud or remote infrastructure, local_file works only on the machine running terraform apply.

The most commonly used arguments are:

• filename — The full path to the file Terraform should create, including the file name and extension.
• content — The text content written to the file. You can use Terraform’s templatefile() function or string interpolation to make it dynamic.
• file_permission — An optional four-digit octal string, such as "0644", that controls the file’s Unix permissions. It defaults to "0777".
• directory_permission — Controls permissions for any intermediate directories Terraform creates along the path. It also defaults to "0777".

For binary content, you can use content_base64 instead of content to write base64-encoded data directly to disk.

If you need to write sensitive content, use the local_sensitive_file resource instead. It works the same way but keeps the content out of Terraform plan diffs, which prevents accidental exposure of secrets.

Terraform local_file use cases

You can use Terraform local_file to render dynamic configuration files, generate scripts from computed values, export outputs in formats other tools can consume, or create bootstrap files for downstream automation. Terraform creates the file during apply and deletes it during destroy.

The most common use cases include:

1. Generating environment configuration files – Write .env, .conf, or config.yaml files populated with values from freshly provisioned infrastructure, such as database hostnames, API endpoints, or storage bucket names.
2. Building inventory files for configuration management tools – After provisioning servers, automatically write an Ansible hosts.ini, a Chef node list, or a similar inventory file using the actual IP addresses and hostnames Terraform created.

Other tasks include rendering and saving startup or bootstrap scripts, exporting Terraform outputs for downstream tooling, or generating kubeconfig or credentials files.

Example 1: Generating a .env file from Terraform variables

One of the most practical uses of local_file is rendering a .env file from values Terraform already knows, such as database endpoints, API URLs, or resource names it just provisioned.

In this example, Terraform takes three input variables and writes them to a .env file in the same directory as the module.

variable "db_host" {  
  description = "The hostname of the database"  
  type        = string  
}

variable "app_port" {  
  description = "The port the application listens on" 
  type        = number  
  default     = 3000 
}

variable "environment" {  
  description = "Deployment environment name"  
  type        = string  
  default     = "production"  
}

resource "local_file" "app_env" {  
  filename        = "${path.module}/.env"  
  file_permission = "0640"

  content = <<-EOT
    APP_ENV=${var.environment}  
    DB_HOST=${var.db_host} 
    APP_PORT=${var.app_port} 
  EOT  
}

The <<-EOT heredoc syntax lets you write multi-line content cleanly. The dash strips leading whitespace from each line, so you can indent the content to match your code without that indentation appearing in the output file. The file_permission value of "0640" makes the file readable by the owner and group, but not by others.

This pattern removes the need to maintain environment files manually. Every time your infrastructure changes and you run apply, Terraform regenerates the .env file with the latest values.

If your application reads from this file at startup, you get consistent, infrastructure-driven configuration without copy-paste errors.

Example 2: Building an Ansible inventory file after provisioning EC2 instances

Once Terraform creates cloud resources, other tools often need access to that data. Ansible, for example, needs an inventory file that lists the IP addresses of the hosts it should manage.

Instead of exporting IPs manually, you can have Terraform generate the inventory file for you.

resource "aws_instance" "web" {
  count         = 3
  ami           = var.ami_id
  instance_type = "t3.micro"

  tags = {
    Name = "web-server-${count.index + 1}"
  }
}

resource "local_file" "ansible_inventory" {
  filename        = "${path.module}/inventory/hosts.ini"
  file_permission = "0644"

  content = templatefile("${path.module}/templates/hosts.ini.tpl", {
    web_ips = aws_instance.web[*].public_ip
  })
}

With the template file at templates/hosts.ini.tpl containing:

[webservers]
%{ for ip in web_ips ~}
${ip}
%{ endfor ~}

After Terraform provisions the three EC2 instances, it collects their public IP addresses with the splat expression aws_instance.web[*].public_ip. Terraform then passes that list to templatefile(), which writes each IP on its own line under the [webservers] group header.

The resulting hosts.ini file is valid Ansible inventory that you can use directly with:

ansible-playbook -i inventory/hosts.ini

The %{ ... ~} trimming markers remove extra whitespace, so the output stays clean.

Because local_file depends implicitly on aws_instance.web, Terraform waits until all three instances are ready before writing the file.

Key points

The local_file resource lets you generate configuration files, scripts, and rendered templates directly from Terraform. This keeps file generation declarative, version-controlled, and integrated with your infrastructure as code workflow.

Terraform is really powerful, but to achieve an end-to-end secure GitOps approach, you need to use a product that can run your Terraform workflows. Spacelift takes managing Terraform to the next level by giving you access to a powerful CI/CD workflow and unlocking features such as:

• Policies (based on Open Policy Agent)
• Multi-IaC workflows
• Self-service infrastructure
• Integrations with any third-party tools

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Note: New versions of Terraform are released under the BUSL license, but everything created before version 1.5.x remains open source. OpenTofu is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.