OpenTofu for coding agents

When a coding agent edits files that describe infrastructure, OpenTofu shows the agent what cloud resources the changes would affect before a person updates them. OpenTofu is an infrastructure as code tool. It reads configuration files that describe your infrastructure and compares them with the state, which is OpenTofu’s record of the infrastructure it manages. From that comparison it creates a plan. Its command-line program is named tofu, and the OpenTofu CLI documentation covers its commands.

An agent can make a small change to the configuration and run tofu plan for review. Planning can contact cloud providers or a remote state backend to read current information, but it does not apply the proposed infrastructure changes. tofu apply performs those changes. Keep credentials outside the agent prompt, and require a person to review any plan that could affect real infrastructure.

Install and check OpenTofu

The installation guide has a page for each operating system and package manager. On macOS or Linux with Homebrew, the documented commands are:

brew update
brew install opentofu
tofu version

tofu version prints the OpenTofu version and the providers installed for the current directory. Add -json if a script or agent should read that information as JSON.

OpenTofu configuration is written in a syntax called HCL, which other HashiCorp products also use. A provider is a plugin that lets OpenTofu work with a service such as a cloud platform. The OpenTofu Registry lists providers and mirrors the documentation of many of them.

For a real cloud configuration, the agent needs access to the provider’s credentials and, when configured, the state backend, which stores OpenTofu’s record of the infrastructure it manages. OpenTofu does not provide one universal cloud login: each provider has its own authentication method. The tofu login command has a different job. It gets an API token for a TACOS platform, which is a hosted service that runs OpenTofu and can store its state. Set cloud credentials through the provider’s supported environment variables or credential mechanism, and check the provider’s official documentation for the required setup. Do not paste secrets into an agent prompt or commit them to the repository.

Preview a local configuration

An agent can practice reviewing a plan with a configuration that does not depend on a provider or module. Create a directory and save this as main.tf:

variable "environment" {
  type    = string
  default = "dev"
}

output "deployment_name" {
  value = "demo-${var.environment}"
}

Then run:

tofu init
tofu plan

tofu init prepares the working directory. It sets up the state backend and installs the providers and modules the configuration asks for. This example has no backend block, so OpenTofu uses its default local backend, which keeps state in a file in the current directory. It does not need to download a provider or module. tofu plan evaluates the configuration and shows the proposed result. The configuration declares no resources, so the only change the plan can propose is the new deployment_name output with the value demo-dev. These commands operate on the local example; they do not create cloud resources.

In a cloud project, OpenTofu can also contact the configured backend and providers when you run these commands. By default, planning reads the current state of existing remote objects before it compares them with the configuration. plan previews infrastructure changes and may make network calls to the configured services. Review the plan command documentation before choosing options for a project.

Keep applying changes separate

OpenTofu’s plan command can save a reviewed plan to a file with -out:

tofu plan -out=tfplan

The file holds the full configuration and the values of the planned changes, including input variables. Sensitive values can be stored in it as plain text unless plan encryption is turned on. A person can inspect the saved plan before anything changes:

tofu show -plan=tfplan

OpenTofu changes infrastructure when you apply the saved plan with a separate command:

tofu apply tfplan

The apply command documentation says that OpenTofu does not ask for confirmation when you pass a saved plan file. It treats the file as the approval. So an agent should prepare and explain the plan, and a human should decide whether to apply it. Treat saved plans and state files as sensitive project data, and follow the project’s rules for storing or sharing them.

A useful agent prompt for the local example is: “Read main.tf, run tofu init and tofu plan, then summarize the planned output and any resource changes. Do not run tofu apply.” For a cloud project, add the relevant directory and review requirements, but keep credentials out of the prompt.

Check repository contribution rules

Working with OpenTofu in an infrastructure repository is different from contributing to OpenTofu’s source code. The OpenTofu repository’s AGENTS.md prohibits contributions generated by large language models. If someone found a bug with the help of an LLM, the file asks them to open an issue and leave out any code for a fix. It does not accept a pull request in that case. An agent should follow that repository-specific rule and should not generate contributions to the OpenTofu project itself.