Terraform Provisioners and Why To Avoid Them

Last Updated on August 11, 2025 by Arnav Sharma

In the vast landscape of Infrastructure as Code (IaC), Terraform stands out as a leading tool, enabling developers and operations teams to define and provision infrastructure using a declarative configuration language. One of its intriguing features is the use of ‘provisioners’, which allow for the execution of scripts or actions during various stages of a resource’s lifecycle. While they offer a powerful way to integrate custom logic into your infrastructure setup, they come with their own set of considerations and best practices. In this blog post, we’ll delve deep into Terraform provisioners, exploring their types, use cases, potential pitfalls, and how to wield them effectively in your IaC journey.

There are two types of Terraform provisioners:

local-exec Provisioner:

• This provisioner invokes a local executable, i.e., on the machine where Terraform is being run.
• It’s often used for tasks like invoking local scripts or tools after a resource has been created.

Example:

resource "aws_instance" "example" {
  # ... instance configuration ...

  provisioner "local-exec" {
    command = "echo The instance ID is ${aws_instance.example.id} > instance_id.txt"
  }
}

remote-exec Provisioner:

• This provisioner invokes a command or script on a remote resource, typically a newly created virtual machine or instance.
• It requires some form of remote connection to the machine, usually SSH for Linux-based systems or WinRM for Windows-based systems

Example:

resource "aws_instance" "example" {
  # ... instance configuration ...

  provisioner "remote-exec" {
    inline = [
      "echo 'Hello, World!' > /tmp/greeting.txt",
      "cat /tmp/greeting.txt"
    ]
  }

  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("~/.ssh/id_rsa")
    host        = self.public_ip
  }
}

While they can be powerful, there are several reasons why they should be used as a last resort:

1. Imperative vs. Declarative: Terraform’s core principle is to provide a declarative way to define infrastructure. Provisioners introduce an imperative approach, which can lead to unpredictable results.
2. State Management: If a provisioner fails, Terraform might end up in a state where it believes a resource was not created, even if it was. This can lead to inconsistencies in the state file and make it difficult to manage and troubleshoot.
3. Idempotency: Terraform resources are designed to be idempotent, meaning you can run the same code multiple times and get the same result. Provisioners can break this idempotency, especially if the scripts they run are not carefully designed.
4. Retry Logic: Terraform has built-in retry logic for providers. If a provisioner fails, there’s no built-in mechanism to retry the provisioner without recreating the entire resource.
5. Tight Coupling: Using provisioners can tightly couple your infrastructure code with configuration management or application setup. This can make it harder to change one without affecting the other.
6. Limited Debugging: Debugging provisioners, especially remote-exec ones, can be challenging. The logs might not be as detailed, and you might need to jump through hoops to get the necessary debugging information.
7. Scalability: Provisioners can introduce scalability issues. For instance, if you’re spinning up many instances and each has a provisioner that takes a long time to run, it can significantly slow down the entire process.
8. Security Concerns: Using provisioners, especially remote ones, can introduce security risks. You might need to open up additional ports or provide credentials, which can be a potential attack vector.
9. Alternative Tools: There are often better-suited tools for configuration management and initialization tasks, like Ansible, Chef, Puppet, or cloud-init. These tools are designed specifically for these tasks and can provide more features and better reliability.
10. Future Deprecation: HashiCorp, the company behind Terraform, has mentioned in various forums and discussions that they see provisioners as a last resort and might deprecate them in the future. Relying heavily on them now might lead to challenges down the road.