Terraform for coding agents

When a coding agent works with cloud infrastructure, it can use Terraform to describe the resources it wants in text files and preview changes before creating or updating them. Terraform's command-line tool reads and checks those files, then creates a plan showing the changes Terraform intends to make.

An agent with shell access can use Terraform to update configuration and run a read-only plan for review. The agent should leave terraform apply, which carries out the planned changes, as a separate, explicitly approved step. HashiCorp's Terraform CLI documentation describes the commands used below.

Install Terraform and prepare credentials

Install Terraform with the instructions for your platform on HashiCorp's installation page. For macOS, that page uses HashiCorp's own Homebrew tap:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Then check that your shell can find it:

terraform version

The example below uses a built-in Terraform resource, so it needs neither cloud credentials nor an external provider. When a configuration uses a cloud service, its Terraform provider (the plugin that connects Terraform to that service) handles authentication. Configure credentials through the provider’s documented method, such as an environment variable or local credential profile. Keep secrets out of the agent prompt and source files.

For HCP Terraform, HashiCorp’s hosted service for running Terraform and storing state (Terraform’s record of managed resources), terraform login gets an API token. By default it saves the token in plain text in a local file called credentials.tfrc.json. That login does not authenticate a cloud provider. You configure provider credentials separately.

Preview a local change

A small local example lets an agent practice the Terraform workflow without creating cloud resources. In a new directory, create main.tf:

resource "terraform_data" "example" {
  input = "agent-review"
}

Terraform's built-in terraform_data resource stores a value in state. It does not create an external cloud resource, and you don't configure a provider for it. It arrived in Terraform 1.4, so older versions don't know it. The agent can initialize the directory, check the configuration, then preview the change:

terraform init
terraform validate
terraform plan

terraform init prepares the working directory. This configuration has no backend block, so Terraform uses its default local backend, which keeps state in a file on disk. terraform validate checks that the configuration is syntactically valid and internally consistent. It does not check remote services such as remote state or provider APIs. terraform plan compares the configuration with the current state and shows the changes Terraform proposes.

For this example, the plan describes adding the terraform_data.example object. Terraform does not contact a cloud provider or create infrastructure. The plan previews the change without applying it.

In a project that already has a remote backend, an agent can still validate the code without touching that backend. The validate documentation shows terraform init -backend=false for this. The init documentation recommends that flag only for a directory that was already initialized for its backend, which is why the new example above uses plain terraform init.

In a real cloud configuration, Terraform can contact remote services to refresh resource information and evaluate data sources. Data sources are configuration blocks that read information from outside Terraform. The plan does not apply changes, but Terraform can still make network calls while creating it. Review the configured providers, backend, and plan before running any command that applies changes.

Keep applying changes separate

After an operator approves a plan, terraform apply makes the planned changes and updates Terraform state, which tracks managed resources. That state can contain sensitive values. A remote backend lets users and Terraform runs share state. It also makes backend access and permissions part of infrastructure work. Read HashiCorp’s state documentation before choosing where state lives.

To save a plan for review, use terraform plan -out=tfplan; the command writes the plan to a file and displays it. Applying a saved plan uses terraform apply tfplan. Terraform applies a saved plan without asking for confirmation, so that command belongs to the operator after the review. The plan documentation also warns that a saved plan file holds sensitive values in cleartext, even when the terminal output hides them. Treat that file as part of the change being reviewed, and do not publish it.

A useful agent prompt for the local example is:

In this directory, inspect main.tf. Explain what terraform_data.example represents, then run terraform init, terraform validate, and terraform plan. Do not run terraform apply or add cloud providers. Report validation errors and summarize the proposed change.

HashiCorp also publishes Agent Skills for Terraform and Packer. These are instructions a coding agent can load when it needs them. They add guidance for the agent. The agent still runs the Terraform commands above and follows the provider documentation for credentials.