Open Source Infrastructure as Code Tools

Why Infrastructure as Code Matters

Before infrastructure as code, provisioning servers and cloud resources meant clicking through web consoles, running ad-hoc shell commands, or following runbooks that quickly fell out of date. This approach created several persistent problems: environments drifted apart because manual steps were applied inconsistently, disaster recovery was slow because recreating infrastructure required remembering dozens of configuration decisions, auditing changes was impossible because there was no record of who changed what and when, and scaling required duplicating manual work linearly.

IaC solves these problems by treating infrastructure definitions as source code. You write files that describe the resources you need, store them in Git alongside your application code, and use tooling to apply those definitions to your actual infrastructure. Changes go through pull requests with code review. The history of every infrastructure modification lives in the Git log. Environments are consistent because they are all built from the same definitions. And scaling means changing a number in a configuration file rather than repeating a manual process.

IaC tools generally fall into two categories: provisioning tools that create and manage cloud resources (virtual machines, networks, databases, load balancers), and configuration management tools that set up the software running on those resources (installing packages, managing config files, starting services). Some teams use one tool for both, while others pair a provisioning tool with a configuration management tool for comprehensive coverage.

Terraform

Terraform, created by HashiCorp in 2014, is the most widely adopted open source IaC provisioning tool. It uses a declarative approach: you write configuration files in HCL (HashiCorp Configuration Language) that describe the desired state of your infrastructure, and Terraform figures out what actions are needed to reach that state from the current state.

A Terraform workflow has three core steps. First, terraform init downloads the provider plugins needed for your configuration (AWS, Azure, Google Cloud, Cloudflare, and hundreds more). Second, terraform plan compares your configuration against the current state of your infrastructure and shows exactly what will be created, modified, or destroyed. Third, terraform apply executes the planned changes. This plan-then-apply workflow gives operators a chance to review changes before they take effect, which is critical when a misconfigured resource could cause an outage.

Terraform tracks the current state of managed resources in a state file. This file records the mapping between resources defined in your configuration and the actual resources that exist in your cloud provider. The state file can be stored locally for individual use, or in a shared backend like S3 with DynamoDB locking, Terraform Cloud, or a PostgreSQL database for team collaboration. State management is one of Terraform's most important and most complex aspects, since corrupted or out-of-sync state can lead to dangerous plan outputs.

Modules are Terraform's mechanism for code reuse. A module is a directory of .tf files that encapsulates a set of related resources with input variables and output values. The Terraform Registry hosts thousands of community-contributed modules for common patterns like VPC creation, EKS cluster provisioning, and RDS database setup. Organizations typically build their own internal module libraries that encode company-specific standards and compliance requirements.

In August 2023, HashiCorp changed Terraform's license from the Mozilla Public License 2.0 (MPL-2.0) to the Business Source License 1.1 (BSL-1.1). The BSL restricts using Terraform in commercial products that compete with HashiCorp's offerings. For most end users provisioning their own infrastructure, the license change has no practical impact. For companies building managed services or commercial platforms on top of Terraform, the change is significant and prompted the creation of OpenTofu.

OpenTofu

OpenTofu is an open source fork of Terraform created in September 2023 in direct response to HashiCorp's license change. It was initially organized by a coalition of companies including Gruntwork, Spacelift, Env0, and Scalr, and it was accepted into the Linux Foundation in January 2024. OpenTofu is licensed under the MPL-2.0, the same license Terraform used before the change, ensuring it remains freely usable without restrictions.

OpenTofu forked from Terraform 1.6 and maintains compatibility with Terraform's configuration language, provider ecosystem, state format, and module registry. Existing Terraform configurations work with OpenTofu with minimal or no changes. The tofu CLI mirrors the terraform CLI, so tofu init, tofu plan, and tofu apply work identically. Terraform providers and modules from the Terraform Registry are compatible with OpenTofu.

OpenTofu has introduced features not present in Terraform, including client-side state encryption (encrypting the state file at rest without relying on the backend's encryption), early variable and local evaluation, and a provider-defined functions framework. The project maintains its own registry at registry.opentofu.org and has an active development community with regular releases.

For organizations choosing between Terraform and OpenTofu, the decision often comes down to licensing philosophy and vendor relationship. If you use HashiCorp's commercial products (Terraform Cloud, Vault, Consul) and value an integrated ecosystem, Terraform remains a practical choice. If open source licensing is a priority, or if you build commercial tools that interface with IaC, OpenTofu provides the same capabilities without licensing constraints.

Ansible

Ansible, originally created by Michael DeHaan in 2012 and acquired by Red Hat in 2015, is the most popular open source configuration management and automation tool. Unlike Terraform, which focuses on provisioning cloud resources, Ansible excels at configuring servers after they are created: installing packages, managing configuration files, deploying applications, orchestrating multi-server workflows, and running ad-hoc commands across fleets of machines.

Ansible's defining characteristic is its agentless architecture. It connects to managed machines over SSH (or WinRM for Windows) and executes tasks remotely. There is no software to install on managed hosts, no daemons to maintain, and no ports to open beyond SSH. This makes Ansible trivial to adopt incrementally: point it at an existing server, write a playbook, and run it.

Ansible playbooks are written in YAML and describe a sequence of tasks to execute on target hosts. Each task calls a module, and Ansible ships with over 3,000 modules covering package management (apt, yum, dnf), file operations (copy, template, lineinfile), service management (systemd, service), cloud resources (ec2, azure_rm, gcp_compute), container operations (docker_container, k8s), database administration, and much more.

Roles organize playbooks into reusable components. A role packages tasks, handlers, files, templates, and variables into a directory structure that can be shared and composed. Ansible Galaxy, the community hub for roles, hosts thousands of pre-built roles for common tasks like configuring Nginx, deploying PostgreSQL, hardening SSH, and setting up monitoring agents. Collections, introduced in Ansible 2.10, extend the role concept to also include modules, plugins, and documentation in distributable packages.

Ansible can also provision cloud resources through its cloud modules, but this is not its primary strength. For organizations that use both Terraform and Ansible, a common pattern is: Terraform provisions the cloud resources (VPCs, instances, databases), then Ansible configures the software on those resources (installs packages, deploys applications, manages configurations). Terraform handles the "what exists" and Ansible handles the "what runs on it."

Pulumi

Pulumi takes a fundamentally different approach to infrastructure as code by using general-purpose programming languages instead of domain-specific configuration languages. You define infrastructure in Python, TypeScript, JavaScript, Go, C#, Java, or YAML, using real code with loops, conditionals, functions, classes, and exception handling. The resulting program produces a desired state that Pulumi's engine reconciles against reality, similar to Terraform's declarative model but expressed through imperative code.

The advantage of using real programming languages is significant for complex infrastructure. You can write a for loop that creates fifty similar resources with different parameters instead of copying a resource block fifty times. You can define a function that encapsulates your organization's standard resource configuration and call it from multiple projects. You can write unit tests that validate your infrastructure definitions before deploying them. And you can use your language's package manager (pip, npm, go modules) to distribute reusable infrastructure components.

Pulumi supports the same cloud providers as Terraform because it can use Terraform providers through a bridging mechanism. AWS, Azure, Google Cloud, Kubernetes, Cloudflare, and hundreds of other providers work with Pulumi. The Pulumi Crosswalk libraries provide higher-level abstractions for common patterns, such as creating an AWS VPC with sensible defaults in a single function call rather than defining subnets, route tables, and security groups individually.

The trade-off is that Pulumi's general-purpose code approach can be harder to audit and review than Terraform's declarative HCL. A Terraform plan shows exactly what will change in a human-readable diff. A Pulumi preview does the same, but the underlying code that produces the plan may be spread across functions, classes, and imported modules, making it harder to understand the full picture from reading the source alone. Teams with strong software engineering practices adapt well to Pulumi, while teams more comfortable with configuration files may prefer Terraform or OpenTofu.

Other IaC Tools

Chef uses a Ruby-based DSL to define system configurations as "recipes" organized into "cookbooks." It follows a client-server model where a Chef client on each managed node periodically pulls its desired configuration from a central Chef Server. Chef was one of the earliest configuration management tools and has a mature ecosystem, though its market share has declined as Ansible's agentless approach gained popularity.

Puppet uses its own declarative language to define system configurations as "manifests" organized into "modules." Like Chef, it uses a client-server model with agents on managed nodes. Puppet excels at enforcing desired state continuously, automatically correcting configuration drift on managed systems. It is still widely used in large enterprises with established Puppet infrastructure.

SaltStack (Salt), now part of VMware, combines configuration management with event-driven automation. Salt uses a master-minion architecture with ZeroMQ for fast communication, and it can manage thousands of nodes with sub-second response times. Its event bus system allows reactive automation, where changes on one system automatically trigger actions on others.

Choosing Your IaC Strategy

Most organizations benefit from pairing a provisioning tool with a configuration management tool. Terraform or OpenTofu handles cloud resources, and Ansible handles server configuration. This separation of concerns keeps each tool's configuration focused and maintainable.

If your team has strong software engineering skills and complex infrastructure requirements, Pulumi's programming language approach may be more natural than HCL. If you are starting fresh and want the most straightforward path, Terraform (or OpenTofu) plus Ansible covers the broadest range of infrastructure automation needs with the largest community support base.