Introduction

• Where provisioners fit into the Terraform lifecycle and the events that trigger them.
• Remote provisioners (remote-exec) that run commands on provisioned infrastructure (for example, using SSH or WinRM via the resource’s connection settings).
• Local provisioners (local-exec) that run on the machine executing Terraform—useful for orchestration or invoking external tooling.
• Key considerations and risks such as idempotency, dependency handling, error handling, and why provisioners are generally a last-resort approach.

​

What are provisioners?

• Running one-off bootstrap commands on newly-created compute instances.
• Copying files to instances after creation.
• Triggering external orchestration or deployment scripts that cannot be implemented via providers.

• remote-exec — executes commands on the target machine via SSH or WinRM.
• file — copies files to the target machine.
• local-exec — executes commands on the Terraform host machine.

​

Lifecycle and trigger points

• create (default): Runs after a resource is created.
• destroy (optional): Runs when the resource is being destroyed if you set when = "destroy".

provisioner "local-exec" {
  when    = "destroy"
  command = "echo 'resource destroyed' >> destroy.log"
}

​

Remote provisioner example (remote-exec)

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

  provisioner "file" {
    source      = "setup.sh"
    destination = "/tmp/setup.sh"

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

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

    inline = [
      "chmod +x /tmp/setup.sh",
      "sudo /tmp/setup.sh",
    ]
  }
}

• Always prefer provider/user-data/user-data cloud-init for initial configuration where possible.
• Connection reliability and network reachability are common causes of failure for remote-exec.

​

Local provisioner example (local-exec)

resource "null_resource" "notify" {
  provisioner "local-exec" {
    command = "curl -X POST -d 'status=created' https://deployment.example.com/hook"
  }

  # Ensure this runs only after a different resource finishes
  depends_on = [aws_instance.web]
}

​

Remote vs Local: quick comparison

​

Key considerations and risks

• Idempotency: Provisioner scripts should be idempotent to survive retries or partial failures.
• Ordering: Terraform’s graph determines ordering. Use explicit depends_on when needed.
• Error handling and retries: Provisioners can fail due to transient issues (network, SSH availability). Implement retries inside scripts and make Terraform handle failure paths.
• State drift: Provisioners may cause changes that are not reflected in Terraform state; prefer declarative approaches when possible.
• Security: Avoid embedding secrets directly in provisioners. Use secure secret solutions (e.g., vaults, cloud provider secret stores).
• Testing: Provisioner logic should be tested independently of Terraform to reduce deployment surprises.

​

Best practices and alternatives

• User-data / cloud-init for OS-level bootstrapping.
• Provider-native configuration options or post-create APIs exposed by the provider.
• Configuration management tools (Ansible, Chef, Puppet) or immutable images (bake configuration into AMIs/VM images).
• Orchestration frameworks (Terraform + Packer) to pre-bake artifacts.

• Keep scripts small and idempotent.
• Use file to copy scripts and remote-exec to execute them.
• Use when = "destroy" sparingly and only for meaningful cleanup tasks.
• Use depends_on to express explicit ordering where required.
• Add retries and exponential backoff in scripts to handle transient failures.

​

Resources and further reading

• Terraform Provisioners Documentation
• Terraform Best Practices
• Cloud-init documentation
• Ansible — Configuration Management