Terraform

Terraform lets teams describe infrastructure as reviewable text, then reconcile real cloud resources against that description.

How it works

The workflow has three stages: write configuration, plan, apply. You declare the end state you want, and Terraform builds a dependency graph of resources so independent ones can be created in parallel. terraform plan compares configuration with the recorded state and with the real infrastructure, and shows what would be created, changed or destroyed. terraform apply then carries out those operations in dependency order.

Providers are plugins that translate configuration into API calls for a platform such as AWS, Azure, Google Cloud, Cloudflare or GitHub. HashiCorp and the community publish thousands of them on the Terraform Registry.

State is the record that maps each resource in your configuration to a real object. By default it is a local file, which is risky for teams. HashiCorp recommends a remote backend or HCP Terraform, with locking and access control, and advises against keeping state in version control because it can contain secrets.

A practical example

resource "aws_s3_bucket" "logs" {
  bucket = "example-team-logs"
}

Running terraform plan shows one resource to add. Running terraform apply creates the bucket and records it in state. Changing the configuration later and planning again shows an in-place change or a replacement, so reviewers see the impact before approval.

Common mistakes

• Keeping state locally or in a shared folder without locking, which leads to conflicting applies.
• Editing the state file by hand. Use the terraform state commands instead.
• Applying without reading the plan, especially lines marked for destruction or replacement.
• Putting every environment in one configuration, so a small change has a large blast radius.
• Leaving ClickOps changes in the console, which create drift between code and reality.

When to use it and when not to

Terraform suits repeatable, multi-cloud or multi-account infrastructure where change review matters. It is less suited to configuring software inside servers, where Ansible is the usual tool, and may be unnecessary for a single short-lived experiment. See our Terraform infrastructure as code service, the Terraform technology page, and the Terraform vs CloudFormation comparison.

See also

• Infrastructure as Code
• ClickOps
• Ansible
• Terraform remote state setup