What is Terraform?

Published on 30 Aug 2025 by Adam Lloyd-Jones

Before the advent of tools like Terraform, managing the digital backbone of any organization was a monumental and often chaotic undertaking. Imagine a world where every server, every database, and every piece of network configuration was meticulously crafted and maintained by hand. This traditional approach, sometimes derisively called “ClickOps” due to its reliance on manual user interface interactions, was not only time-consuming but also riddled with challenges that often led to frustration and critical errors.

This response will delve into the origins of Terraform, exploring the landscape of infrastructure management that necessitated its creation, its fundamental principles, and its journey as a pivotal tool in the modern cloud era.

The Era of Manual Infrastructure Management: A Foundation of Fragility

In the not-so-distant past, the software industry operated with a clear division: “Developers” wrote the code, and “Operations” (sysadmins) managed the physical hardware that ran it. As infrastructure needs grew, this manual approach faced escalating complexity. Setting up a simple cloud network, for instance, could take days, even for experienced professionals, because it involved configuring dozens of interconnected components.

The challenges were multifaceted:

Human Error and Inconsistency: Manual tasks are inherently prone to mistakes. A slight misconfiguration by one person could lead to system outages or security vulnerabilities. Without a standardized process, infrastructure deployments often varied, even for identical systems, leading to “configuration drift” where systems diverged from their intended state.
Slowness and Tedium: Deploying and scaling infrastructure was a slow, laborious process. Each change required repetitive manual steps, bogging down teams and delaying software releases. This repetitive work offered no creativity or challenge, leading to stress and resentment among operations teams.
Lack of Visibility and Traceability: Changes made manually were often poorly documented, making it difficult to track who did what, when, and why. Debugging problems or auditing changes became a detective’s task, searching through logs or relying on institutional knowledge.
Scalability Nightmares: Managing a handful of servers might be straightforward, but scaling to hundreds or thousands of instances, databases, and load balancers across multiple regions and cloud providers quickly became overwhelming.
Ad-Hoc Scripting Pitfalls: To combat manual repetition, teams often turned to “ad hoc scripts” using general-purpose programming languages like Bash or Python. While these offered some automation, they lacked a consistent structure, leading to custom code for every task and different styles across developers. This made scripts hard to maintain, especially for complex infrastructure.

This “dark and fearful age” was characterized by the fear of downtime, accidental misconfiguration, and slow, fragile deployments. It became evident that a more systematic, automated, and codified approach was necessary to manage the growing demands of modern IT infrastructure.

The Dawn of Infrastructure as Code (IaC)

The solution to these pervasive problems arrived in the form of Infrastructure as Code (IaC). IaC is a practice that treats infrastructure—servers, databases, networks—like software. Instead of manual clicks or ad-hoc scripts, IaC involves writing your desired architecture configuration in code. This code is then stored, version-controlled, and managed with the same rigor and best practices as application code. The benefits of adopting IaC were transformative:

Automation: IaC allows for the automation of infrastructure deployments, significantly reducing or eliminating the need for manual intervention. This frees up IT teams to focus on strategic tasks rather than day-to-day management.
Consistency and Reliability: By defining infrastructure in code, IaC ensures that deployments are consistent and repeatable. It eliminates configuration drift, as applying the definition will always bring a system back into its intended state. This predictability enhances reliability and reduces errors.
Speed and Efficiency: With automation, infrastructure can be provisioned and updated much faster than manual processes. This rapid deployment capability is crucial for business agility and scaling.
Version Control and Collaboration: IaC configurations are stored in version control systems (like Git). This enables teams to track changes, review code, collaborate effectively, and even revert to previous, known-good versions of their infrastructure if problems arise.
Documentation: The code itself serves as clear, human-readable documentation of the infrastructure. This transparency promotes understanding among team members and simplifies maintenance.
Cost Management: By defining infrastructure clearly, IaC can help in estimating costs before deployment and understanding the financial impact of changes.

IaC fundamentally shifted the mindset from managing infrastructure directly to managing it indirectly through code. This change paved the way for specialized tools that could interpret this code and translate it into real-world infrastructure.

Terraform: HashiCorp’s Open Source Vision

Among the array of IaC tools that emerged, Terraform, created by HashiCorp, rapidly rose to prominence as a key player. Released as an open-source project and written in the Go programming language, Terraform was designed to define infrastructure as code using a simple, declarative language. Its goal was to address the core challenges of infrastructure management by providing a unified, flexible, and automated solution.

Several core features differentiated Terraform and contributed to its widespread adoption:

Declarative Configuration Language (HCL): This is perhaps Terraform’s most defining characteristic.
- Instead of writing step-by-step instructions (how to do something), Terraform users simply define the desired state of their infrastructure (what they want it to look like).
- Human-Readable: Terraform utilizes the HashiCorp Configuration Language (HCL), which is designed to be easy for humans to read and write, even for those with limited programming experience.
- Idempotence: A key benefit of declarative definitions is that they lend themselves to idempotent operations. This means you can safely apply your configurations repeatedly without worrying about unintended side effects. If a system is changed outside of Terraform, reapplying the definition will bring it back into line, eliminating configuration drift.
- Simplified Logic: Terraform’s engine automatically figures out the necessary steps to transition the current infrastructure to the desired state, including dependency resolution. This reduces the need for complex procedural logic in the code itself, allowing teams to focus on the outcome rather than the intricate process.
Extensive Provider Ecosystem: Terraform’s versatility comes from its “provider ecosystem”. A Terraform provider acts as a bridge between Terraform and external APIs (Application Programming Interfaces), allowing it to manage resources across a vast array of platforms.
- Multi-Cloud and Beyond: This means Terraform can manage infrastructure on major public cloud providers (like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)), private cloud and virtualization platforms (like OpenStack), and even third-party services like DNS providers or Git repositories. Terraform provides a single unified interface to thousands of different vendors and software systems.
- Abstraction: Providers abstract away the vendor-specific details and APIs, so users interact with a consistent Terraform language, regardless of the underlying platform.
State Management: Terraform keeps track of all the resources it has created and manages in a state file. This file is a critical component that links the real-world infrastructure to your Terraform configuration.
- Tracking and Consistency: The state file allows Terraform to understand what currently exists, compare it with your desired configuration, and then accurately determine what changes (additions, modifications, or deletions) are needed. It ensures that Terraform always knows which resources it controls and their attributes.
- Collaboration: For teams, state files need to be stored remotely (e.g., in a cloud storage bucket) and often require state locking to prevent multiple users from making conflicting changes simultaneously.
Modularity for Reusability: Terraform emphasizes creating reusable infrastructure components called modules. Any set of Terraform configuration files in a folder can be considered a module.
- Building Blocks: Modules allow teams to package common infrastructure patterns (like a web server cluster with a load balancer) into easily consumable units. This promotes the “Don’t Repeat Yourself” (DRY) principle, avoiding code duplication.
- Configurability: Modules can be made configurable using input variables (parameters) and output variables (values returned by the module), allowing for flexible adaptation across different environments or projects.

The Basic Terraform Workflow: A Predictable Path

Terraform provides a clear and repeatable workflow that guides users through the process of provisioning and managing infrastructure:

terraform init (Initialization): This is the first command executed in a new (or cloned) Terraform project. It prepares the working directory by:
- Discovering and downloading the necessary provider plugins (e.g., for AWS, Azure, GCP).
- Setting up the backend configuration, which determines where the Terraform state file will be stored (locally or remotely).
- Downloading any referenced modules.
terraform plan (Planning): After writing or modifying the configuration files, terraform plan is run to preview the changes Terraform will make. This crucial step:
- Compares the desired state (defined in your code) with the current state (recorded in the state file and refreshed from the real infrastructure).
- Generates an execution plan that details exactly what actions Terraform proposes to take (e.g., resources to add, change, or destroy).
- Crucially, it does not make any actual changes to your infrastructure. This allows for review and validation, catching potential errors before deployment.
terraform apply (Application): Once the plan is reviewed and approved, terraform apply is executed to implement the proposed changes.
- Terraform then makes the necessary API calls to the cloud providers to create, update, or destroy resources according to the plan.
- For automation, the -auto-approve flag can be used to bypass the interactive confirmation.
terraform destroy (Destruction): When infrastructure is no longer needed, terraform destroy can be used to tear down all resources managed by the current configuration. This command also generates a plan and requires confirmation (unless -auto-approve is used).

Beyond these core commands, Terraform also includes utilities like terraform fmt to automatically format code for consistent style and terraform validate to check configuration for syntax errors and structural validity.

Evolution and the OpenTofu Fork

Terraform’s journey, though relatively young, has been marked by rapid development and a growing, active community. Initially championed for its open-source nature and vendor-agnostic approach, it quickly became a standard for IaC. This led to the emergence of an entire ecosystem of Terraform Automation and Collaboration Software (TACOS) solutions, which integrated Terraform into continuous integration/continuous delivery (CI/CD) pipelines, offered state management, and provided private module registries.

However, in late 2023, HashiCorp announced a significant license change for Terraform, moving it from the open-source Mozilla Public License (MPL) to a proprietary Business Source License (BSL). This decision sparked considerable debate and concern within the community, particularly among companies whose products were built upon the previously open-source Terraform. In response, a coalition of companies and individual developers launched OpenTofu, an open-source fork of Terraform. OpenTofu aims to preserve Terraform’s open-source principles and continue its development under a permissive license.

Compatibility: So far, OpenTofu has maintained significant compatibility with Terraform, allowing users to largely interchange their code. However, OpenTofu is also beginning to implement community-requested features, potentially making it a “superset” of Terraform’s language with new functionalities.
Community Governance: To ensure its long-term open-source commitment, OpenTofu has been accepted into the Linux Foundation and is working towards joining the Cloud Native Computing Foundation (CNCF). This places the project under vendor-neutral governance, assuring the community it won’t be subject to the whims of a single company.
Tooling Impact: The license change has also affected how Terraform is distributed. Many open-source package managers (like Homebrew) have ceased carrying new versions of HashiCorp Terraform beyond v1.5.7, while OpenTofu continues to be supported by most of these managers.

This fork marks a new chapter in Terraform’s history, highlighting the community’s commitment to open-source IaC tools while solidifying Terraform’s role as a foundational technology regardless of its specific lineage.

Conclusion

Terraform emerged from a clear necessity: to bring order, automation, and reliability to the increasingly complex world of infrastructure management. By championing a declarative language (HCL), fostering a rich provider ecosystem, and implementing robust state management, Terraform transformed how organizations define, deploy, and manage their digital infrastructure.

From its beginnings as an open-source tool, it empowered developers and operations teams to treat infrastructure as code, applying software engineering best practices like version control and modularity to traditionally manual processes. Despite recent shifts in its licensing model and the emergence of OpenTofu, Terraform’s core principles and its enduring impact on the IaC landscape remain undiminished. It continues to be a powerful and essential tool for automating tasks, ensuring consistency, and elevating infrastructure management to new heights of efficiency and scalability in the modern cloud-native era.

Adam Lloyd-Jones

Adam is a privacy-first SaaS builder, technical educator, and automation strategist. He leads modular infrastructure projects across AWS, Azure, and GCP, blending deep cloud expertise with ethical marketing and content strategy.