What Is Terraform? Infrastructure as Code, Explained

Terraform is an open-source infrastructure-as-code (IaC) tool created by HashiCorp that lets you define cloud and infrastructure resources in configuration files and provision them in a repeatable, automated way. Instead of clicking through a cloud console or running ad-hoc scripts — a pattern often called click-ops — you describe the desired state of your infrastructure and Terraform figures out how to get there.

It is one of the most widely used IaC tools, supporting hundreds of providers: AWS, Google Cloud, Azure, Cloudflare, Kubernetes, GitHub, Datadog, and far more. If a service has an API, there is almost certainly a Terraform provider for it.

How Terraform works

Terraform uses HCL (HashiCorp Configuration Language), a declarative syntax designed to be both human-readable and machine-friendly. A minimal example that creates an AWS S3 bucket looks like this:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-app-assets-prod"
}

You declare resources — the concrete objects you want to exist — and providers supply the logic to create, update, or delete them via their APIs.

The plan/apply workflow

Terraform’s core loop has two steps:

1. terraform plan compares your configuration against the current recorded state of your infrastructure and shows exactly what will be created, modified, or destroyed — before touching anything. This diff is safe to review, commit to a PR, and discuss with teammates.
2. terraform apply executes the plan. Terraform calls each provider’s API to make reality match your configuration.

This workflow makes infrastructure changes reviewable and auditable in a way that scripted deployments rarely are. It fits naturally into a CI/CD pipeline where a plan runs on every pull request and apply runs after merge.

The state file

Terraform tracks what it has provisioned in a state file (terraform.tfstate). The state file is Terraform’s source of truth for what currently exists, separate from both your configuration and the actual cloud APIs. It enables incremental updates: Terraform only changes what has actually diverged from configuration.

In teams, the state file lives in remote state backends — S3, Terraform Cloud, or Google Cloud Storage — so collaborators share the same view and locking prevents concurrent applies from conflicting.

Providers and modules

Providers are plugins that translate Terraform resource declarations into API calls. You declare a provider in your configuration and Terraform downloads it from the public registry on terraform init.

Modules are reusable collections of resources. A team might publish a vpc module that encapsulates a standard network layout, or a web-app module that packages a load balancer, auto-scaling group, and DNS record together. Modules turn common infrastructure patterns into composable building blocks — reducing duplication and enforcing internal standards. Combined with platform engineering practices, modules let teams offer self-service infrastructure without exposing raw Terraform complexity.

Why IaC matters

Before tools like Terraform, infrastructure lived in the heads of sysadmins and in the click histories of cloud consoles. The problems this creates are well-known:

• Configuration drift — servers that were manually tweaked no longer match each other.
• No audit trail — you cannot git blame a console click.
• Slow recovery — rebuilding from scratch after a failure requires tribal knowledge.

With Terraform, your infrastructure is code: version-controlled, diff-able, peer-reviewed, and revertable. Provisioning a new environment is a matter of running terraform apply against a new workspace, not a weeks-long manual process. This pairs naturally with containerization — Docker packages applications, while Terraform provisions the infrastructure those containers run on — and with orchestrators like Kubernetes.

OpenTofu: the open-source fork

In 2023 HashiCorp changed Terraform’s license from the Mozilla Public License to the Business Source License (BSL), restricting commercial competitors from building products directly on Terraform. The community response was OpenTofu, a foundation-governed fork of Terraform under the Linux Foundation that remains MPL-licensed. OpenTofu is largely compatible with Terraform HCL and is actively maintained. For teams wary of a commercial dependency, it is a viable alternative.

Terraform vs. cloud-native tools

AWS CloudFormation, Azure Bicep, and Google Cloud Deployment Manager each do IaC for their own cloud. Terraform’s advantage is its multi-cloud and multi-service scope: a single configuration can wire together an AWS RDS database, a Cloudflare DNS record, and a GitHub Actions secret. For teams running multi-cloud or heavily integrated stacks — including serverless platforms alongside traditional VMs — that breadth is hard to replace.

The takeaway

Terraform turns infrastructure into version-controlled code: you declare what you want, plan shows what will change, and apply makes it happen. State tracks reality, modules enable reuse, and a vast provider ecosystem means nearly any cloud resource can be managed this way. Whether you adopt Terraform or its open-source sibling OpenTofu, treating infrastructure as code is one of the highest-leverage practices a DevOps team can adopt.