What Is Terraform? Infrastructure as Code, Explained

Terraform is an open-source infrastructure as code (IaC) tool from HashiCorp that lets engineers define servers, networks, databases and other cloud resources in text files, then have a single command create, change or tear down that infrastructure safely and in the right order. Instead of clicking through a cloud console or stringing together one-off scripts, teams write what they want their infrastructure to look like, let Terraform compare that against what actually exists, and approve a plan before anything changes.

What is Terraform, exactly?

Terraform is HashiCorp's tool for building, changing and versioning infrastructure "safely and efficiently," as the company's own documentation puts it on its Terraform introduction page. Rather than provisioning a virtual machine, a load balancer or a database by hand, an engineer writes a configuration file describing the resources they want. Terraform reads that file, works out what needs to happen to make reality match it, and then does the work through each provider's API.

That configuration is written in HCL, the HashiCorp Configuration Language — a format designed to be both human-readable and machine-parsable — although Terraform also accepts JSON. Because the infrastructure definition lives in a plain text file rather than in a person's memory of which buttons they clicked, it can be stored in version control, reviewed like any other code change, copied between environments, and audited after the fact. This is the essence of what the industry calls infrastructure as code: treating servers and networks the same way software teams treat application code.

Terraform was first released by HashiCorp in 2014 and has become one of the most widely used IaC tools. Since February 2025 it has been owned by IBM, which completed its acquisition of HashiCorp and folded Terraform and Vault into IBM's automation software portfolio, according to IBM's own newsroom announcement. HashiCorp continues to develop and ship Terraform as a product within IBM.

How Terraform differs from clicking around a cloud console

Most people's first experience provisioning cloud infrastructure is through a web console — logging into AWS, Azure or Google Cloud and manually creating a virtual machine, a storage bucket or a security rule by filling in forms. That works for a quick experiment, but it has three problems at scale:

• It isn't repeatable. Rebuilding the same environment for staging, disaster recovery or a second region means remembering and re-clicking every setting, which invites drift and human error.
• It isn't reviewable. A console change has no diff. Nobody can look at a pull request and see exactly what is about to change before it happens.
• It isn't portable across providers. Each cloud has its own console, its own terminology and its own automation API, so skills and scripts built for one don't transfer directly to another.

Ad-hoc scripts (a collection of AWS CLI or Azure CLI commands, for example) solve some of this but are typically imperative: they describe the steps to take, not the end state, so they have to account for whether a resource already exists, whether a previous run partially failed, and what order operations must happen in. Terraform is declarative — engineers describe the desired end state, and Terraform's own dependency graph works out the order of operations and which resources can be created in parallel, rather than the author having to script that sequencing by hand.

The core workflow: write, plan, apply

HashiCorp's documentation describes Terraform's standard lifecycle in three steps, and this cycle is the thing most "what is Terraform" explanations are really trying to get across:

The plan step is the part manual console changes and most scripts don't give you: a preview of the blast radius of a change before it happens. Nothing is touched until a human (or a CI pipeline) approves that plan, which is also why Terraform fits naturally into the kind of reviewable, pull-request-driven process described in this site's plain-English explainer on DevOps.

Terraform state: how it knows what already exists

To compute a plan, Terraform needs a record of what it created last time, not just the live cloud environment and the current configuration file. That record is called state, and by default Terraform keeps it in a local JSON file named terraform.tfstate. According to HashiCorp's state documentation, "Terraform must store state about your workspace's managed infrastructure and configuration," and it uses that state "to determine which changes to make to your infrastructure" on each run. State is essentially the binding between the resources declared in configuration and the real objects those resources map to in AWS, Azure, Google Cloud or wherever they were created.

Because the state file can contain sensitive values and needs locking to prevent two people from applying changes at once, HashiCorp's own guidance is to avoid storing it in version control and instead use a remote backend, or a managed option like HCP Terraform, when more than one person works on the same infrastructure.

Providers: how Terraform talks to the cloud

Terraform itself doesn't know anything about AWS, Kubernetes or Cloudflare out of the box. That knowledge lives in providers — plugins that translate Terraform's generic resource blocks into calls against a specific platform's API. HashiCorp's documentation puts it directly: providers "enable Terraform to work with virtually any platform or service with an accessible API." Thousands of providers, covering the three major public clouds as well as SaaS tools, networking appliances and on-prem systems like VMware, are published on the public Terraform Registry, which is also where community and HashiCorp-maintained modules live.

This provider model is what makes Terraform a multi-cloud tool rather than an AWS-only or Azure-only one: the same HCL syntax and the same write/plan/apply workflow apply whether the resource block underneath targets a virtual machine, a DNS record, or a Kubernetes namespace, which is a different layer of the stack than the container orchestration covered in explainers on Kubernetes or Docker.

Modules: packaging infrastructure for reuse

Once a team has written a working configuration for, say, a standard web application stack — a load balancer, an autoscaling group and a database — they typically don't want to copy and paste that configuration every time they need another copy of it. Terraform's answer is modules. HashiCorp's own modules documentation defines a module simply as "a collection of resources that Terraform manages together," and recommends that teams "write reusable modules" for any pattern they deploy more than once, in order to standardize how infrastructure gets provisioned and to deploy new resources faster and more consistently.

Every Terraform configuration has at least a root module, and that root module can call child modules — sourced from the local filesystem, the public registry, or a private registry run through HCP Terraform or Terraform Enterprise. In practice, most organizations end up with a small library of internal modules (a "standard VPC," a "standard Kubernetes cluster") that application teams reuse rather than writing raw provider resources from scratch.

Why teams adopt Terraform

The appeal of Terraform over manual console work or ad-hoc scripting comes down to a handful of practical benefits:

• Consistency across environments. The same configuration (with different variables) can build identical staging, production and disaster-recovery environments.
• Change review before execution. The plan step turns infrastructure changes into something a reviewer can read and approve, the same way they'd review an application code change.
• Multi-cloud and multi-service reach. One workflow and one language cover AWS, Azure, Google Cloud and thousands of other services through providers, instead of learning each vendor's own console and CLI.
• A record of how infrastructure got the way it is. Because configuration lives in version control, teams can see who changed what and why, rather than reconstructing history from console audit logs.
• Collaboration at scale. HashiCorp's managed HCP Terraform service, built on the open-source core, adds shared remote state, access controls and a private module registry for organizations where many people run Terraform against the same infrastructure.

None of this is unique to one cloud or one kind of workload — the same write/plan/apply loop applies whether a team is standing up serverless functions, virtual machines, or the identity and access plumbing behind something like an OAuth-protected API. Terraform manages the infrastructure those systems run on; it generally isn't the layer that configures application-level authentication logic itself, but the two are often provisioned through the same pipelines.

Open source, licensing, and the OpenTofu fork

Terraform's source code is published on GitHub under HashiCorp's account, where the project describes itself as a tool that "enables you to safely and predictably create, change, and improve infrastructure." It's worth knowing the project's licensing has changed over its history: Terraform was originally released under the open-source Mozilla Public License 2.0, but in August 2023 HashiCorp relicensed it under the Business Source License (BUSL) 1.1, a source-available license that restricts building directly competing commercial products on top of it. In response, a group of users and vendors forked the pre-relicense codebase into a project originally called OpenTF and now known as OpenTofu, which is maintained under the Linux Foundation on the older MPL terms. Most day-to-day Terraform usage — writing configuration, running plans and applies against your own infrastructure — is unaffected by the license change; it mainly matters to companies building and selling a competing Terraform-as-a-service product.

Getting started with Terraform

A minimal first project usually looks like: install the Terraform CLI, write a small configuration file declaring one resource (a storage bucket or a single virtual machine is a common first exercise), run terraform init to download the relevant provider plugin, run terraform plan to see what would be created, and then terraform apply to create it. From there, teams typically move state to a remote backend before more than one person touches the same configuration, and start factoring repeated patterns out into modules. HashiCorp's own getting-started tutorials on its developer site walk through this sequence against AWS, Azure, Google Cloud and other providers using free-tier resources.

What's next

Terraform's write/plan/apply loop, provider ecosystem and module system have made it one of the default ways teams manage cloud infrastructure as code, and that hasn't changed with its move under IBM's ownership. Where to look next depends on what you're trying to do: HashiCorp's own tutorials are the fastest way to run a first plan and apply against a real provider, the public Terraform Registry is where to find existing providers and modules before writing your own, and the OpenTofu project is worth knowing about if licensing terms matter for your organization. For the broader practices Terraform typically sits inside — version control, CI/CD, and treating operations like software engineering — see this site's explainer on what DevOps is.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage