Terraform

Terraform is a command-line tool that turns text files into running infrastructure. Instead of clicking through the AWS console to create a server, a database, and a load balancer, you describe them in a file and run one command. Terraform talks to the provider's API and builds everything for you.

The configuration language is called HCL (HashiCorp Configuration Language). It is declarative, which means you describe the end result you want, not the step-by-step instructions to get there. You say I want three EC2 instances and an S3 bucket, and Terraform figures out the order to create them and the dependencies between them.

Terraform is provider-agnostic. The same tool manages AWS, Google Cloud, Azure, Cloudflare, Datadog, GitHub, Kubernetes, and over 3,000 other services through plugins called providers. One workflow covers your whole stack, not just one vendor.

The core of Terraform is the state file, usually named terraform.tfstate. It is a JSON record of every resource Terraform created and the real-world IDs that map to your config. When you run terraform plan, it reads your config, reads the state, queries the live providers, and computes the difference. The output is an exact list of what it will add, change, or destroy before anything happens.

terraform apply executes that plan. Terraform builds a dependency graph so it knows that a subnet must exist before the instance that lives in it, and it parallelizes everything that has no dependency on each other. terraform destroy walks the graph in reverse to tear it all down.

Because the state file is the source of truth, teams almost never keep it on a laptop. They store it in a remote backend like an S3 bucket with DynamoDB locking, Terraform Cloud, or Google Cloud Storage. The lock stops two engineers from running apply at the same time and corrupting the state. Sensitive values like passwords end up in this file in plain text, so the backend must be encrypted and access-controlled.

Reach for Terraform when you provision infrastructure repeatedly, across environments, or as a team. Spinning up identical staging and production setups, version-controlling your network design, and reviewing infrastructure changes in a pull request are all things Terraform does well. The plan output alone, showing exactly what will change before it changes, prevents a lot of 2 AM mistakes.

The main trade-offs are state management and drift. The state file is fragile. If someone changes a resource by hand in the console, Terraform sees drift on the next plan and may try to undo it. Importing existing resources into state is tedious. And HCL is good at provisioning but weak at procedural logic, so complex loops and conditionals get awkward.

Terraform provisions infrastructure but does not configure what runs inside it. It will create a server, but installing and starting your application is a job for Ansible, cloud-init, or a container image. People often confuse Terraform with configuration management tools like Ansible or Chef. They solve different parts of the problem and are frequently used together. Note that since version 1.6 HashiCorp moved Terraform to the Business Source License, which prompted the community fork OpenTofu, a drop-in open-source replacement.

Suppose a startup runs the same web app in dev, staging, and production. Without Terraform, an engineer clicks through three sets of VPCs, subnets, security groups, RDS databases, and EC2 instances, and the three environments slowly drift apart. With Terraform, the whole stack lives in a few .tf files, and a variable switches the environment name and instance size.

To launch a fresh staging environment, the engineer runs terraform workspace select staging, then terraform plan to preview, then terraform apply. In a couple of minutes the entire environment exists and is byte-for-byte identical in shape to production. To save money overnight, terraform destroy removes it, and the same apply rebuilds it tomorrow.

Reusable pieces are packaged as modules. A team might publish a vpc module and a database module, then every project consumes them with a few lines, so a network change made once propagates everywhere it is used. This is how companies manage thousands of resources without losing track of any of them.