AWS with Terraform (Day 19)

Terraform Provisioners Explained: local-exec, remote-exec, and file

Provisioners in Terraform are often misunderstood. Many beginners either overuse them or avoid them entirely without understanding where they fit. In this post, I’ll explain what Terraform provisioners actually do, when they make sense, and how local-exec, remote-exec, and file provisioners behave in real-world scenarios, based on a hands-on EC2 demonstration.

This was part of my Day 19 learning, focused on understanding the imperative escape hatch Terraform provides when declarative resources alone are not enough.

What are Terraform Provisioners?

A provisioner allows Terraform to execute imperative actions during a resource’s lifecycle, usually at creation time or destruction time.

Provisioners are commonly used for:

  • Bootstrapping instances

  • Copying files to servers

  • Running scripts or commands that Terraform resources cannot express directly

Terraform documentation clearly states that provisioners should be used sparingly. Whenever possible, prefer:

  • Cloud-init / user data

  • Native Terraform resources

  • Immutable images (AMIs)

  • Configuration management tools

Provisioners are best treated as a last-mile tool, not a primary design pattern.

Provisioner Types in Terraform

Terraform supports three commonly used provisioners:

  • local-exec

  • remote-exec

  • file

Each one serves a different purpose.

local-exec Provisioner

The local-exec provisioner runs commands on the machine where Terraform itself is executed, not on the cloud resource.

When to use local-exec

  • Generating files locally

  • Calling external CLI tools

  • Logging or notifying systems during apply

  • Triggering scripts in CI/CD pipelines

Key point

local-exec does not require SSH, keys, or network access to the resource. It runs entirely on your local system or CI runner.

Because it runs locally, it is not suitable for server bootstrapping.

remote-exec Provisioner

The remote-exec provisioner runs commands on the remote resource itself, typically over SSH.

Common use cases

  • Installing packages

  • Creating files or directories

  • Running setup commands after instance creation

Requirements

To use remote-exec, you must define a connection block:

  • SSH user

  • Private key

  • Host (usually the instance public IP)

You must also ensure:

  • Security groups allow SSH

  • Private key permissions are correct

  • The instance is reachable when Terraform runs

Because remote-exec depends on SSH connectivity, it is more fragile than cloud-init and should be used carefully.

file Provisioner

The file provisioner copies files from the local machine to the remote instance over SSH.

Typical usage

  • Uploading scripts

  • Copying configuration files

  • Transferring certificates or assets

The file provisioner does not execute anything. It only copies files. In most cases, it is paired with a remote-exec provisioner to run the uploaded script.

Using the self Object

Inside a resource block, Terraform exposes a special object called self.

Useful attributes include:

  • self.id

  • self.public_ip

  • self.private_ip

These attributes are commonly used in provisioners and connection blocks to dynamically reference the resource being created.

Forcing Provisioners to Re-run

Terraform provisioners run only when a resource is created or recreated.

If the resource has no changes, provisioners will not execute again.

To force a re-run during testing:

terraform taint aws_instance.example
terraform apply

This marks the resource for recreation, triggering all provisioners again.

Practical Observations

From hands-on testing, a few important lessons stand out:

  • local-exec is excellent for automation around Terraform, not inside servers

  • remote-exec and file depend heavily on network stability and SSH correctness

  • Provisioner failures can taint resources and cause unexpected recreations

  • Sensitive data should never be hardcoded inside provisioner commands

  • Provisioners increase coupling between infrastructure and configuration

Best Practices

  • Prefer cloud-init or user data for instance bootstrapping

  • Use provisioners only when declarative resources are insufficient

  • Keep provisioner logic simple and idempotent

  • Avoid long-running or complex scripts inside provisioners

  • Always destroy test resources to avoid unnecessary costs

Diagram




Final Thoughts

Terraform provisioners are powerful, but they are not the default solution. They exist to bridge the gap between declarative infrastructure and imperative configuration when no better option is available.

Here is the session link:



Comments

Post a Comment

Popular posts from this blog

AWS with Terraform (Day 01)

Image
  Terraform Fundamentals – Day 01 (My Learning Notes as a DevOps Engineer) Today I wrapped up Day-01 of my Terraform with AWS series, and even with my DevOps background, this session helped me tighten my fundamentals and rethink how I approach cloud provisioning. Terraform is something I’ve used before, but today was more about understanding why IaC matters at scale and why Terraform continues to dominate in real-world DevOps ecosystems. Understanding Infrastructure as Code (IaC) As a DevOps engineer, IaC is not new to me. But today’s session broke it down in a way that clarified its real value. IaC = Infrastructure represented as code. Instead of building resources manually through AWS/Azure/GCP consoles, we define everything in .tf files. This ensures our setup is predictable, repeatable, and version-controlled. What I liked most is how clearly the contrast was shown: Cloud-Agnostic Tools (Terraform / Pulumi) Work across AWS, Azure, GCP, Kubernetes, GitHub, etc. ...
Read more

AWS with Terraform (Day 27)

Image
Automating AWS Infrastructure Using Terraform and GitHub Actions Infrastructure automation is where DevOps truly becomes real. Writing Terraform code is only half the story—the real value comes when infrastructure changes are version-controlled, reviewed, scanned, approved, and applied automatically . On Day 27 of my DevOps journey, I implemented a production-grade CI/CD pipeline to automate AWS infrastructure using Terraform and GitHub Actions , following best practices used in real-world teams. This blog walks through the architecture, workflow design, safety controls, and lessons learned . Why Automate Terraform with CI/CD? Running Terraform manually from a laptop works for learning, but it quickly breaks down in team and production environments: Local state files are risky and hard to share Credentials scattered across machines No standardized reviews or approvals No security or policy checks before apply No clear audit trail By integrating Terraform with G...
Read more

AWS with Terraform (Day 02)

Image
  AWS with Terraform – Day 02 Deep Dive into Providers, Versioning & the Real “Bridge” Between Code and Cloud Today’s session took me from simply writing Terraform code to actually understanding the engine behind it — the Provider layer . And honestly, once this clicks, Terraform stops feeling like just a tool and starts feeling like a real engineering system. Here’s what I learned and how I’ve started applying it. Providers: The Plugin That Makes Terraform Real The simplest way I now understand it: Terraform writes the story. Providers translate it into cloud actions. Before today, I treated the provider block as just two lines of mandatory code. Now I see it as the translator that turns HCL into actual AWS API calls . Example: I write: resource "aws_s3_bucket" "demo" { bucket = "my-app-demo" } The AWS provider turns that into the exact S3 API request. This layer saves us from manually hitting APIs, building payloads, or juggling ...
Read more