What Is Terraform? Infrastructure as Code Explained

Quick answer: Terraform is an infrastructure as code (IaC) tool, originally from HashiCorp, that lets you define cloud and on-premises infrastructure in human-readable configuration files and then create, change, and version it safely. You describe the resources you want, such as servers, networks, and databases, in a declarative language called HCL; Terraform compares that desired state to what actually exists and makes only the changes needed. It works across many platforms through plugins called providers, making it one of the most widely used tools in modern DevOps and cloud engineering.

What is infrastructure as code, and why does it matter?

Infrastructure as code means managing servers, networks, and other resources through configuration files instead of clicking through a web console by hand. The benefits are substantial. Your infrastructure becomes repeatable, because the same files produce the same environment every time. It becomes reviewable, because changes go through version control and code review just like application code. And it becomes recoverable, because you can rebuild an environment from the files if something fails. Terraform is one of the most popular ways to practice IaC, and the approach sits at the heart of what a DevOps engineer does day to day.

How does Terraform actually work?

Terraform follows a clear, repeatable cycle. You write configuration, preview the changes, then apply them. The core workflow is usually summarized as write, plan, apply.

1. Write: You declare resources in .tf files using HCL, for example a virtual machine, a storage bucket, and a network.
2. Init: Running terraform init downloads the providers your configuration needs and prepares the working directory.
3. Plan: Running terraform plan shows exactly what Terraform will create, change, or destroy, without touching anything yet. This preview is one of Terraform’s most valued safety features.
4. Apply: Running terraform apply executes the plan and provisions the real resources, then records the result in state.
5. Destroy: Running terraform destroy tears down everything the configuration manages, which is useful for temporary or test environments.

What are providers?

A provider is a plugin that teaches Terraform how to talk to a specific platform’s API. There are providers for the major clouds such as Amazon Web Services, Microsoft Azure, and Google Cloud, as well as for services like Kubernetes, GitHub, Cloudflare, and many databases. Because of this plugin model, the same tool and workflow can manage wildly different systems. You declare which providers you need, Terraform downloads them during init, and from then on you describe resources using that provider’s resource types. This breadth is a big reason Terraform became an industry standard and why it appears so often in the toolkit of a cloud engineer.

What is Terraform state?

State is where Terraform gets much of its power, and also where beginners hit the most trouble. When Terraform creates resources, it records what it made in a state file that maps your configuration to real-world objects. On the next run, Terraform reads state to understand what already exists, so it can calculate the minimal set of changes rather than recreating everything.

Two practical rules follow from this. First, the state file can contain sensitive data, such as database passwords, so it must be protected. Second, when a team shares infrastructure, everyone must use the same state, so it is stored in a remote backend (for example, cloud object storage) with locking to prevent two people from applying conflicting changes at once. Editing state by hand is risky and generally avoided. Respecting state is the single most important habit for working with Terraform safely.

What does a simple configuration look like?

HCL is designed to be readable. A configuration declares resources in blocks, each with a type, a name, and settings. You reference one resource from another so Terraform can work out the correct order, for example creating a network before the server that uses it. You can also use variables to avoid hardcoding values, outputs to surface useful results like an IP address, and modules to package and reuse groups of resources. Because the files are plain text, they live in version control alongside everything else, which connects naturally to our guide on what Git is.

Terraform vs. other tools

Terraform is frequently compared to other infrastructure tools, and the distinctions matter when choosing the right one.

A key point for 2026: in August 2023, HashiCorp changed Terraform’s license from the open-source MPL 2.0 to the Business Source License (BSL), which restricts using the software to build directly competing products. In response, several companies created OpenTofu, an MPL 2.0 fork now governed by the Linux Foundation and accepted into the Cloud Native Computing Foundation in 2025. OpenTofu reads the same HCL, uses the same providers, and writes a compatible state file, so for most users the two are interchangeable in daily work. Which one a team chooses is largely a governance and licensing decision. Treat specific version numbers as fast-moving and verify the current release before relying on a particular feature.

What are common Terraform use cases?

• Standing up cloud environments such as development, staging, and production that are identical and reproducible.
• Multi-cloud or hybrid deployments, using one workflow across more than one provider.
• Disposable environments for testing or demos that can be created and destroyed on demand.
• Managing supporting services like DNS records, access policies, and Kubernetes clusters.

Because it defines whole environments as code, Terraform is a core skill for anyone designing large systems, which is why it features in paths toward becoming a cloud architect and in the reliability practices described in our comparison of DevOps and SRE.

What are modules, and why do teams use them?

As configurations grow, copying the same blocks across projects becomes unmanageable. Modules solve this by packaging a group of resources into a reusable unit with defined inputs and outputs. For example, a team might build a module that creates a standard network with the right subnets, routing, and security rules, then reuse it across every environment by simply passing different variables. Modules encourage consistency, reduce copy-paste errors, and let a team encode its best practices once. Public registries host thousands of community modules for common patterns, though production teams often write and version their own. Thinking in modules is a sign of maturity with Terraform, and it mirrors how good software is factored into reusable components.

What are the main benefits and trade-offs of Terraform?

Terraform’s strengths explain its popularity, but it is worth being honest about the trade-offs too.

• Benefit: multi-cloud consistency. One workflow and language manage many platforms, so teams do not relearn a new tool for each provider.
• Benefit: safe previews. The plan step shows every change before it happens, which prevents many costly mistakes.
• Benefit: repeatability and auditability. Because everything is code in version control, environments are reproducible and every change is traceable.
• Trade-off: state complexity. Managing state, backends, and locking correctly takes discipline and is the most common source of real-world problems.
• Trade-off: learning curve. The declarative mindset and provider-specific details take time to internalize, especially for those used to clicking through consoles.
• Trade-off: drift. If someone changes a resource by hand outside Terraform, the real world and the state can diverge, requiring care to reconcile.

How does Terraform fit into a CI/CD pipeline?

In mature teams, Terraform rarely runs from a laptop for production changes. Instead, configuration lives in a Git repository, and a continuous integration pipeline runs terraform plan automatically on every pull request so reviewers can see exactly what will change. After approval, an automated step runs terraform apply against the target environment. This brings the same review, testing, and audit discipline to infrastructure that teams already apply to application code. It also enforces that state lives in a shared remote backend rather than on any individual’s machine, which is essential once more than one person is involved. This automation-first approach is a defining feature of modern platform teams.

How should a beginner start with Terraform?

Begin with one provider you already understand, ideally a cloud you have used through its console. Install Terraform (or OpenTofu), create a single small resource such as a storage bucket, and run through init, plan, and apply to feel the workflow. Pay close attention to the plan output before every apply; reading plans carefully is a professional habit worth building early. Store your configuration in Git from day one, keep secrets out of your files, and move to a remote backend for state as soon as more than one person is involved. Avoid the temptation to copy large, complex configurations you do not understand; small steps that you can explain will teach you far more.

Is Terraform worth learning?

For anyone heading into DevOps, cloud, or platform engineering, Terraform is one of the most valuable skills available. It is widely adopted, transferable across clouds, and central to how modern teams build and change infrastructure safely. The declarative model takes a short while to internalize, and state management demands respect, but the payoff is large: you gain the ability to describe entire environments as reviewable, repeatable code. Whether you ultimately use Terraform or its OpenTofu fork, the concepts carry over, making the learning durable regardless of how the tooling evolves.