What is Terraform?

Terraform, a popular Infrastructure as Code (IaC) tool, provides a solution to efficiently manage infrastructure. This post explains what Terraform is, its core concepts, and its place in the IaC landscape.

What is Infrastructure as Code (IaC)?

Before we jump straight into Terraform, lets discuss the broader topic of Infrastructure as Code, which Terraform is part of. IaC is the practice of managing and provisioning infrastructure through code instead of manual processes. This means defining your servers, databases, networks, and other cloud resources in configuration files that can be version-controlled, tested, and deployed automatically. IaC brings the benefits of software development practices to infrastructure management, improving consistency, repeatability, and speed.

What is Terraform?

Terraform is a Infrastructure as Code tool created by HashiCorp. It allows you to define and provision an entire infrastructure using a declarative configuration language named HCL. Terraform supports a wide range of cloud providers (like AWS, Azure, Google Cloud), on-premise solutions, and other services through its provider ecosystem.

Why Use Terraform vs. Other IaC Tools?

While other IaC tools exist (e.g. AWS CloudFormation, Azure Resource Manage), Terraform stands out for the following reasons:

• Cloud Agnostic: Terraform works across multiple cloud providers and services. This allows you to manage diverse infrastructure from a single tool, coding language and helps in avoiding vendor lock-in.
• Declarative Syntax: You define the desired state of your infrastructure, and Terraform figures out how to achieve it. This simplifies configuration and reduces errors.
• Extensibility: Terraform's provider model allows it to integrate with virtually any platform that exposes an API.
• State Management: Terraform maintains a state file that tracks the real-world infrastructure it manages, enabling it to perform intelligent updates and detect configuration drift.

What Are the Key Components of Terraform?

Terraform Core Binary

Terraform Core is the main executable that acts as the brain of the operation. It interprets your written configuration files, understands the desired state of your infrastructure, and communicates with the various providers to achieve that state. It also plays a crucial role in managing the Terraform state file.

Providers

Providers are plugins that serve as the bridge between Terraform Core and your infrastructure. Each provider is responsible for understanding how to interact with a specific cloud platform or service's API. For example, the aws provider knows how to create and manage resources in Amazon Web Services, while the azurerm provider handles resources in Microsoft Azure. This modular design allows Terraform to support a vast array of services.

Resources

Within your Terraform configuration, resources are the fundamental building blocks that represent individual infrastructure objects. These could be anything from a virtual machine instance, a database, a network subnet, or even a DNS record. Each resource block defines the desired properties and configuration for that specific infrastructure component.

Data Sources

Data sources allow Terraform to fetch information about existing infrastructure or external data that is not managed by your current Terraform configuration. This is useful when you need to reference resources created outside of Terraform or retrieve dynamic information that influences your infrastructure setup. For instance, you might use a data source to get the ID of an existing VPC to deploy resources into.

Modules

Modules are self-contained, reusable packages of Terraform configurations. They promote modularity, organization, and reusability by allowing you to encapsulate common infrastructure patterns. Instead of writing the same resource blocks repeatedly, you can define them once in a module and then reference that module across different projects or environments, reducing duplication and improving consistency.

Variables

Terraform variables serve as placeholders for dynamic values within your infrastructure configurations, allowing you to make your code reusable and adaptable without directly modifying the core configuration files. Instead of hardcoding values like region names, instance types, or resource tags, you can define variables and assign different values to them depending on the environment (development, staging, production) or specific deployment needs. This approach enhances flexibility, maintainability, and collaboration by centralizing configurable parameters and enabling consistent infrastructure deployments across various scenarios.

State File

The Terraform state file (by default, terraform.tfstate) is a crucial component that records the mapping between your Terraform configuration and the real-world infrastructure it manages. This file tracks the current state of your resources, their attributes, and dependencies. Terraform uses the state file to understand what changes need to be made during plan and apply operations, and to detect any configuration drift that may have occurred outside of Terraform.

What is the Core Terraform Workflow?

The typical Terraform workflow involves the following main steps:

Write: Define your infrastructure using HashiCorp Configuration Language (HCL) in .tf files.

Init: terraform init is the first command you run in a new or cloned Terraform project to initialize the working directory, download necessary provider plugins and modules, and configure the backend for state management.

Plan: Run terraform plan to generate an execution plan. This shows you what changes Terraform will make to your infrastructure before applying them.

Apply: Run terraform apply to execute the planned changes and provision or update your infrastructure.

Basic Example

In the example below, we will use the null resource module to show how the Terraform workflow operates. The null resource provider does not require any credentials, so it makes it an easy provider to learn with:

resource "null_resource" "example" {
  provisioner "local-exec" {
    command = "echo 'Congrats on your first run! Woohoo!!!!'"
  }
}

In the example above, we also used the local exec provisioner to echo a command so we can see some output. The file should be named main.tf (It can be named anything, but must end in .tf)

Run terraform init

terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Installing hashicorp/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

As seen above, the init command finds the providers that are defined and pulls them to prep for the plan and apply.

Run terraform plan to see what the proposed changes are:

terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.example will be created
  + resource "null_resource" "example" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Finally, execute the apply, which will create the resources. In this case, we are creating "fake" resources since we are just using the null_resource provider.

terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # null_resource.example will be created
  + resource "null_resource" "example" {
      + id = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

null_resource.example: Creating...
null_resource.example: Provisioning with 'local-exec'...
null_resource.example (local-exec): Executing: ["/bin/sh" "-c" "echo 'Congrats on your first run! Woohoo!!!!'"]
null_resource.example (local-exec): Congrats on your first run! Woohoo!!!!
null_resource.example: Creation complete after 0s [id=816605688202175000]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

In the example above, it can be seen that an approval was prompted. The option to add an auto-approval exists if the -auto-approve flag is added to the apply command.

History of Terraform: HashiCorp, License Changes, and IBM Acquisition

Terraform was initially released by HashiCorp in 2014 under the Mozilla Public License (MPL) 2.0, making it open-source. For years, it fostered a large and active community.

In August 2023, HashiCorp announced a significant change, switching Terraform's license from MPL 2.0 to the Business Source License (BSL) 1.1. This change restricted how others could use Terraform's source code.

In April 2024, IBM announced its intent to acquire HashiCorp. The acquisition, valued at $6.4 billion, closed on February 27, 2025.

Why OpenTofu Was Forked from Terraform

The shift from MPL to BSL prompted a strong reaction from the open-source community. Many felt the BSL was not truly open source and would hinder innovation and competition. As a direct response to HashiCorp's license change, the Linux Foundation, in collaboration with several organizations (including Scalr) and individual contributors, launched OpenTofu.

OpenTofu is a community-driven, open-source fork of Terraform, continuing under a permissible license (Mozilla Public License 2.0). Its aim is to provide a truly open-source alternative for managing infrastructure, ensuring the project remains community-governed and free from restrictive licensing. OpenTofu represents a commitment to the principles of open source and collaborative development within the IaC ecosystem.