The Infrastructure as Code landscape has been through a violent reshuffling. HashiCorp switched Terraform to BSL, then IBM bought the whole company for $6.4 billion. OpenTofu forked and landed at the Linux Foundation. Chef’s Infra Server hits end-of-life in November 2026. Puppet’s community forked to OpenVox after Perforce restricted binary access. Crossplane graduated from CNCF. Pulumi shipped an AI agent. Podman quietly crossed 23% enterprise market share.
If you picked your IaC stack three years ago and haven’t looked up since, some of those choices aged poorly. This is a no-fluff breakdown of every major infrastructure automation tool as it stands in 2026, with clear recommendations on what’s worth your time and what’s circling the drain. Whether you’re building a new platform team or reevaluating an existing stack, the goal here is to save you from betting on the wrong horse.
Current as of April 2026. All versions, GitHub stars, and project status verified against official sources.
Quick Reference: IaC and Cloud Automation Tools (2026)
This table summarizes every tool covered below. Bookmark it for quick comparisons.
| Tool | Latest Release | License | Status | Best For |
|---|---|---|---|---|
| OpenTofu | Releases | MPL 2.0 | Active, growing | IaC provisioning (open source) |
| Terraform | Releases | BSL 1.1 | Active, IBM-owned | IaC provisioning (existing users) |
| Pulumi | Releases | Apache 2.0 | Active, growing | IaC with real programming languages |
| Ansible | Releases | GPL 3.0 | Active, dominant | Config management, orchestration |
| Crossplane | Releases | Apache 2.0 | CNCF Graduated | Kubernetes-native IaC |
| Packer | Releases | BSL 1.1 | Active | VM image building |
| Docker | Releases | Apache 2.0 | Active, dominant | Container runtime |
| Salt | Releases | Apache 2.0 | Active, stable | Event-driven infrastructure |
| Dagger | Releases | Apache 2.0 | Active, growing | CI/CD pipelines as code |
| Chef | Releases | Apache 2.0 | Declining | Legacy config management |
| Puppet | Releases | Source-available | Declining | Legacy config management |
| Vagrant | Releases | BSL 1.1 | Minimal updates | VM dev environments (legacy) |
1. OpenTofu
OpenTofu is the tool most people should start with for new IaC projects in 2026. It exists because HashiCorp relicensed Terraform from MPL 2.0 to BSL 1.1 in August 2023, and a broad coalition of companies (Spacelift, env0, Gruntwork, Scalr, and others) forked it under the Linux Foundation. The project has since diverged meaningfully from Terraform, with features HashiCorp never shipped.
The latest stable release (check current version) is licensed under MPL 2.0. It remains a drop-in replacement for Terraform in most cases. Existing .tf files, modules, and providers work without modification. The migration path is straightforward: rename your binary and update your state backend configuration.
Where OpenTofu pulls ahead is native state encryption. You can encrypt your state file at rest using AES-GCM, AWS KMS, GCP KMS, or HashiCorp Vault, without any external tooling or wrapper scripts. Terraform still doesn’t offer this natively. For teams that have been piping state through sops or building custom encryption layers, this alone justifies the switch.
Adoption is real. Roughly 50% of Spacelift deployments now use OpenTofu, and the number keeps climbing. The provider ecosystem is fully compatible since providers are published to the OpenTofu Registry and most Terraform providers work unmodified.
Install OpenTofu on Linux with the official installer:
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
chmod +x install-opentofu.sh
./install-opentofu.sh --install-method rpmVerify the installation:
tofu versionRecommendation: Default choice for new IaC projects. If you’re starting fresh, there’s no reason to pick the BSL-licensed option when the open-source fork is feature-complete and actively developed.
Official site: opentofu.org
2. Terraform
Terraform is still the most widely deployed IaC tool, holding roughly 32.8% market share. That number is slowly declining as OpenTofu gains ground, but the installed base is enormous. If your organization already runs Terraform, nobody is going to force you off it tomorrow.
The current release (latest version) ships under the BSL 1.1 license. IBM completed its $6.4 billion acquisition of HashiCorp in February 2025. The license has not reverted to open source under IBM’s ownership, and there’s no indication it will. The BSL means you can use Terraform freely, but you cannot build a competing managed service on top of it.
Terraform’s biggest advantage remains its provider ecosystem. Over 4,000 providers cover virtually every cloud service, SaaS platform, and infrastructure component you can think of. The Terraform Registry is still the largest IaC module library. HCP Terraform (formerly Terraform Cloud) provides state management, policy enforcement, and team collaboration for those willing to pay.
The concern is trajectory. IBM has historically been slow to innovate on acquired products, and the open-source community energy has visibly shifted to OpenTofu. New blog posts, conference talks, and tutorials increasingly favor OpenTofu. That said, Terraform isn’t going anywhere soon. Enterprise contracts run for years, and the tool works fine.
A basic provider configuration for AWS looks identical in both tools:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}You can deploy VM instances on OpenStack with Terraform or use it alongside containers by automating deployments with Docker and Terraform.
Recommendation: Keep using it if you’re already invested. Evaluate OpenTofu for new projects, especially if the BSL license is a concern for your legal team.
Official site: terraform.io
3. Pulumi
Pulumi takes a fundamentally different approach to IaC. Instead of a domain-specific language like HCL, you write infrastructure definitions in Python, TypeScript, Go, C#, or Java. Real programming languages with real IDEs, real debuggers, real testing frameworks, and real package managers. If you’ve ever been frustrated by HCL’s limited expressiveness (and you have, if you’ve used it long enough), Pulumi is the answer.
The latest release (current version) is licensed under Apache 2.0. Pulumi has raised $99 million in funding and employs around 129 people. This is a well-funded project with long-term viability, not a side project that might disappear.
Two recent developments are worth noting. First, HashiCorp deprecated CDKTF (Cloud Development Kit for Terraform) in December 2025. CDKTF let you write Terraform in general-purpose languages, which made it a direct Pulumi competitor. With CDKTF gone, Pulumi is now the clear winner in the “real languages for IaC” category. Second, Pulumi shipped Pulumi Neo, an AI agent that can generate and deploy infrastructure from natural language prompts. It’s early, but it works for straightforward deployments.
Pulumi ESC (Environments, Secrets, and Configuration) handles secrets management across environments. It integrates with Vault, AWS Secrets Manager, and Azure Key Vault, pulling secrets at deployment time without storing them in state.
Here’s a simple S3 bucket definition in Python to show the difference from HCL:
import pulumi
import pulumi_aws as aws
bucket = aws.s3.Bucket("my-bucket",
versioning=aws.s3.BucketVersioningArgs(
enabled=True,
),
tags={
"Environment": "production",
},
)
pulumi.export("bucket_name", bucket.id)That’s just Python. You can loop over it, test it with pytest, import shared libraries, and refactor it with any IDE.
Recommendation: Best choice if your team has strong software engineering skills and finds HCL limiting. The CDKTF deprecation makes the case even stronger.
Official site: pulumi.com
4. Ansible
Ansible dominates configuration management and shows no sign of slowing down. With roughly 68,400 GitHub stars on the core repository, it has the largest community of any tool on this list. The agentless architecture (SSH-based, nothing to install on targets) remains its killer feature. One control node, a YAML playbook, and you’re managing hundreds of servers.
The latest release (current version) ships under GPL 3.0. Red Hat packages the enterprise version as Ansible Automation Platform (AAP) 2.6, which adds a web UI, RBAC, credential management, and workflow orchestration. The open-source upstream for AAP’s automation controller is AWX, which you can self-host.
Event-Driven Ansible (EDA) is the most interesting recent addition. It watches for events from monitoring systems, cloud APIs, or webhooks, then triggers playbooks automatically. Think “when Prometheus fires an alert, scale the deployment.” This moves Ansible from pure configuration management into reactive automation territory.
The ecosystem is massive. Ansible Galaxy hosts thousands of roles and collections. Red Hat certifies collections for major vendors (Cisco, F5, Palo Alto, VMware), which matters in enterprise procurement. Ansible also pairs naturally with Terraform or OpenTofu: use the IaC tool to provision infrastructure, then hand off to Ansible for configuration. That combination covers most needs.
A simple playbook to install and start Nginx on Rocky Linux:
---
- name: Configure web servers
hosts: webservers
become: true
tasks:
- name: Install Nginx
ansible.builtin.dnf:
name: nginx
state: present
- name: Start and enable Nginx
ansible.builtin.systemd:
name: nginx
state: started
enabled: true
- name: Open firewall for HTTP
ansible.posix.firewalld:
service: http
permanent: true
state: enabled
immediate: trueFor a complete walkthrough, see how to install and configure Ansible on Linux.
Recommendation: If you manage servers (physical or virtual), learn Ansible. It’s the default choice for configuration management and orchestration, and it complements every IaC provisioning tool on this list.
Official site: ansible.com
5. Crossplane
Crossplane flips the IaC model on its head. Instead of a separate tool with its own CLI and state file, Crossplane turns Kubernetes itself into your infrastructure control plane. You define cloud resources as Kubernetes Custom Resources (CRDs), and the Crossplane controller reconciles them against your cloud provider. The Kubernetes API becomes your IaC API.
The project reached a major milestone in October 2025 when it graduated from the CNCF, joining Kubernetes, Prometheus, and Envoy at the highest maturity level. The latest release (current version) ships under Apache 2.0. The contributor base has grown to over 3,000, with production adopters including Nike, NASA, SAP, and IBM.
The mental model is different from Terraform. In Terraform, you run terraform apply and it makes API calls to create resources. In Crossplane, you kubectl apply a manifest, and a controller running inside your cluster continuously reconciles the desired state. If someone manually deletes an S3 bucket, Crossplane recreates it. That’s genuine continuous reconciliation, not just “apply and hope.”
Compositions let you build higher-level abstractions. A platform team can define a “Database” composite resource that bundles an RDS instance, security group, subnet group, and parameter group. Application teams then request a “Database” without needing to know the underlying cloud primitives. This is where Crossplane shines for platform engineering.
An example claim for a managed PostgreSQL instance:
apiVersion: database.example.org/v1alpha1
kind: PostgreSQLInstance
metadata:
name: production-db
namespace: team-alpha
spec:
parameters:
storageGB: 100
version: "16"
compositionSelector:
matchLabels:
provider: aws
environment: productionThe application team submits this. The platform team’s Composition handles the rest: VPC, subnet, security group, RDS instance, credentials stored in a Kubernetes Secret.
Recommendation: Excellent for platform teams that are already deep in Kubernetes. If your organization runs everything on K8s and wants a self-service infrastructure platform, Crossplane is the strongest option. Not the right fit if you’re not already committed to Kubernetes.
Official site: crossplane.io
6. Docker
Docker needs no introduction, but the competitive landscape around it has changed. The Docker Engine remains the dominant container runtime (latest release), open-sourced under Apache 2.0. Docker Desktop, the GUI tool for macOS and Windows, requires a paid subscription for companies with 250 or more employees. That licensing change pushed many organizations to explore alternatives.
The containerd image store is now the default backend, replacing the legacy graphdriver storage. This is mostly transparent, but it improves image management and aligns Docker with the broader container ecosystem since containerd is what Kubernetes uses under the hood.
The most significant shift is Podman’s rise. Podman (latest version) has reached 23% enterprise market share as a Docker alternative. It’s rootless by default, daemonless (no persistent background process), and command-compatible with Docker. On RHEL, Rocky Linux, and AlmaLinux, Podman ships in the base repositories and is Red Hat’s officially recommended container runtime. Many teams run Docker in development and Podman in production, or have switched entirely.
Build a container image with Docker:
docker build -t myapp:v1.0 .
docker run -d -p 8080:8080 --name myapp myapp:v1.0The same commands work with Podman by aliasing or replacing the binary:
podman build -t myapp:v1.0 .
podman run -d -p 8080:8080 --name myapp myapp:v1.0For production Kubernetes clusters, the runtime doesn’t matter at the application layer because everything goes through containerd or CRI-O. Where Docker vs. Podman matters is developer workstations and CI/CD pipelines.
Recommendation: Docker is still the safe default for containerization. Learn Podman as well, especially if you work with RHEL-family systems. The two are interchangeable for most workflows.
Official site: docker.com
7. Packer
Packer builds machine images from a single source template. Need an AMI for AWS, a VMware template for vSphere, and a QCOW2 for OpenStack? One Packer template, one build command, three artifacts. That workflow hasn’t changed, and nothing has replaced it.
The current release (latest version) ships under BSL 1.1 (same license change as Terraform). Packer uses HCL2 templates (the older JSON format still works but is considered legacy). The plugin architecture supports builders for every major cloud and virtualization platform.
HCP Packer adds an image registry and lifecycle management layer. It tracks which images are in use, which are outdated, and can revoke deprecated images across your infrastructure. This matters in environments where golden image compliance is a security requirement.
Packer sits alongside container image building, not as a replacement. Containers handle application packaging. Packer handles the base OS images those containers run on. A typical pipeline provisions a base AMI with Packer (OS patches, security hardening, monitoring agents), then deploys containerized applications on top.
A minimal Packer template for building an AWS AMI:
packer {
required_plugins {
amazon = {
version = ">= 1.3.0"
source = "github.com/hashicorp/amazon"
}
}
}
source "amazon-ebs" "rocky10" {
ami_name = "rocky10-base-{{timestamp}}"
instance_type = "t3.micro"
region = "us-east-1"
source_ami_filter {
filters = {
name = "Rocky-10-EC2-Base-*"
root-device-type = "ebs"
virtualization-type = "hvm"
}
owners = ["792107900819"]
most_recent = true
}
ssh_username = "rocky"
}
build {
sources = ["source.amazon-ebs.rocky10"]
provisioner "shell" {
inline = [
"sudo dnf update -y",
"sudo dnf install -y vim curl wget"
]
}
}Recommendation: If you build VM images (AMIs, VMware templates, Proxmox templates), Packer is still the standard. The BSL license is less of a concern here since there’s no real alternative and the tool does one thing well.
Official site: packer.io
8. Salt (SaltStack)
Salt has an interesting ownership history. VMware acquired SaltStack, then Broadcom acquired VMware. Through that chain, Broadcom now owns Salt. Despite the corporate turbulence, the open-source project is actively maintained under Apache 2.0.
Two release tracks exist: STS (short-term support) and LTS (long-term support). Check the Salt releases page for current versions. Salt uses a master-minion architecture with ZeroMQ for communication, which makes it significantly faster than Ansible for large-scale operations. Running a command across 10,000 nodes takes seconds, not the minutes you’d wait with SSH-based tools.
Salt’s event-driven reactor system is genuinely powerful. The Salt event bus captures everything happening across your infrastructure, and reactors can trigger states automatically based on those events. A minion comes online, an event fires, a reactor applies the correct configuration. No human intervention, no scheduled run.
The community is smaller than Ansible’s, and finding Salt-experienced engineers is harder. This is the honest tradeoff. Salt is technically capable, often faster at scale, but the talent pool is thinner and the ecosystem of pre-built formulas is smaller.
A basic Salt state to install and manage Nginx:
nginx:
pkg.installed:
- name: nginx
service.running:
- enable: True
- require:
- pkg: nginx
/etc/nginx/nginx.conf:
file.managed:
- source: salt://nginx/files/nginx.conf
- user: root
- group: root
- mode: 644
- watch_in:
- service: nginxRecommendation: Consider Salt if you manage very large fleets (thousands of nodes) and need speed. For most teams, Ansible’s larger ecosystem and easier hiring make it the pragmatic choice.
Official site: saltproject.io
9. Dagger
Dagger attacks a problem that’s been festering for years: CI/CD pipelines written in YAML are painful to debug, impossible to run locally, and locked to a specific CI vendor. Dagger lets you write your CI/CD pipeline in Go, Python, or TypeScript, then run it identically on your laptop and in GitHub Actions, GitLab CI, or any other CI system.
The latest release (current version) ships under Apache 2.0. Dagger is still pre-1.0, which means the API changes between releases. That’s the honest caveat. The core concept is stable, but expect some migration work as the project matures.
Every pipeline step runs in a container. Dagger builds a DAG (directed acyclic graph) of your pipeline, caches intermediate steps aggressively, and provides full OpenTelemetry tracing out of the box. When a step fails, you get a container you can shell into and debug. Compare that to staring at a failed GitHub Actions log and guessing.
A simple Dagger pipeline in Go:
func (m *MyModule) Build(ctx context.Context, source *dagger.Directory) *dagger.Container {
return dag.Container().
From("golang:1.24").
WithDirectory("/src", source).
WithWorkdir("/src").
WithExec([]string{"go", "build", "-o", "myapp", "."})
}Run that locally with dagger call build --source . and it behaves exactly the same as it would in your CI environment. No more “works on my machine but fails in CI.”
Recommendation: Worth evaluating if your team is frustrated with YAML-based CI/CD. The pre-1.0 status means early adopter risk, but the productivity gains are real for complex pipelines. Not a replacement for simple build-and-deploy workflows where YAML is fine.
Official site: dagger.io
Tools in Decline
Not every tool on this list is worth learning. Some are in maintenance mode, losing community support, or being replaced by better alternatives. Here’s an honest assessment of three tools that are trending downward.
Chef
Chef was once a dominant configuration management tool alongside Puppet and Ansible. Progress Software owns it now, and the trajectory is clear. Chef Infra Server reaches end-of-life in November 2026. The replacement is Chef 360 Platform, a fundamentally different architecture that requires migration, not an upgrade.
The Chef Infra Client (release notes) is licensed under Apache 2.0. The Ruby-based DSL was powerful but had a steep learning curve compared to Ansible’s YAML. Most organizations that used Chef have either migrated to Ansible already or are in the process. The remaining installations tend to be large enterprises locked into long-term support contracts.
The writing has been on the wall for years. Chef’s market share has been declining since 2020, and the talent pool of Chef-experienced engineers is shrinking. New engineers aren’t learning it. Conferences aren’t featuring it. Blog posts aren’t covering it.
Verdict: Do not invest in learning Chef for new projects. If you’re maintaining an existing Chef deployment, start planning the migration to Ansible or Salt before the Infra Server EOL date hits.
Puppet
Puppet’s situation is more dramatic. Perforce (which acquired Puppet in 2022) restricted binary access in 2025, making it harder for the community to use Puppet without a commercial license. The community responded by forking. The Vox Pupuli community created OpenVox (available on GitHub), a free, source-available fork that tracks Puppet compatibility.
The current Puppet version (releases) ships under a source-available license that is more restrictive than Puppet’s original open-source licensing. Puppet still has deep enterprise installations. Banks, telecoms, and government agencies that deployed Puppet a decade ago still run it because migration is expensive and the tool works. ANZ Bank and similar large enterprises aren’t ripping out Puppet anytime soon.
OpenVox is interesting but early. The project needs time to build its own ecosystem and prove long-term viability. Betting on it for production today is risky.
Verdict: Not recommended for new deployments. Existing Puppet shops should monitor OpenVox and plan a gradual transition to Ansible. The restricted licensing under Perforce makes the long-term outlook uncertain.
Vagrant
Vagrant (releases, BSL 1.1) had its last release in August 2025. The planned Vagrant 3.0 rewrite in Go never materialized. Containers, cloud development environments (GitHub Codespaces, Gitpod), and lightweight VMs (Lima, Orbstack) have replaced most of Vagrant’s use cases.
There are still valid niches. Security researchers who need full OS environments for malware analysis, network engineers testing multi-VM topologies, and teams that require exact OS-level parity with production. For these cases, Vagrant still works. For general development environments, it’s been superseded.
Verdict: Don’t adopt it for new projects. If you have Vagrantfiles in your repos that people actually use, they’ll keep working. But don’t build new workflows around it.
OpenTofu vs. Terraform: Head-to-Head
Since these two tools share a common codebase, the comparison comes down to licensing, features, and trajectory. This table captures the state as of April 2026.
| Criteria | OpenTofu | Terraform |
|---|---|---|
| License | MPL 2.0 (open source) | BSL 1.1 (source-available) |
| Latest release | See releases | See releases |
| Governance | Linux Foundation | IBM (via HashiCorp) |
| Native state encryption | Yes (AES-GCM, KMS, Vault) | No |
| Provider compatibility | ~99% Terraform providers work | 4,000+ native providers |
| Module registry | OpenTofu Registry | Terraform Registry (larger) |
| Managed platform | Spacelift, env0, Scalr | HCP Terraform + third-party |
| Community momentum | Growing, active contributions | Stable, some migration out |
| Migration effort | Minimal (rename binary, update backend) | N/A |
For existing Terraform users, the migration to OpenTofu is straightforward. Replace the terraform binary with tofu, update any backend configuration that references Terraform Cloud, and run tofu init. Your .tf files, modules, and state format are compatible. The largest friction point is provider pinning if you’ve locked to specific Terraform Registry URLs.
Provisioning vs. Configuration Management
A common mistake is treating provisioning tools and configuration management tools as interchangeable. They solve different problems and work best together.
Provisioning tools (OpenTofu, Terraform, Pulumi, Crossplane) create infrastructure: VMs, networks, load balancers, DNS records, databases. They talk to cloud APIs and produce infrastructure that exists. They’re declarative (“I want 3 instances behind a load balancer”) and idempotent (“running it again changes nothing if the state matches”).
Configuration management tools (Ansible, Salt, Chef, Puppet) configure what runs on that infrastructure: install packages, deploy configs, manage users, restart services. They operate inside the OS, not at the cloud API level.
The standard pattern in production is to chain them. OpenTofu provisions an EC2 instance, outputs its IP address, and Ansible picks up from there to install the application stack. Some teams use Packer as the bridge: Packer calls Ansible during image builds, so the golden AMI already has everything installed. Then OpenTofu launches instances from that pre-baked image with zero post-boot configuration.
Crossplane blurs this line because it operates at the Kubernetes layer, which is both provisioning and runtime. Pulumi also straddles the boundary since you can shell out to configuration tasks within the same program. But for most teams, the provisioning + config management split remains the cleanest architecture.
IaC Platform Alternatives
Terraform Cloud (now HCP Terraform) used to be the default platform for managing Terraform runs remotely. The BSL license change and IBM acquisition accelerated migration to third-party platforms that support both Terraform and OpenTofu.
Spacelift is the most prominent alternative, supporting Terraform, OpenTofu, Pulumi, Ansible, and CloudFormation in a single platform. About half of Spacelift’s deployments already use OpenTofu. env0 offers similar multi-tool support with strong cost estimation and policy-as-code features. Scalr provides a hierarchical workspace model that works well for large organizations managing hundreds of environments.
All three platforms let you manage state, enforce policies (OPA, Sentinel, or custom), run plans in isolated environments, and integrate with your VCS. The key difference from HCP Terraform is vendor neutrality. You’re not locked to one IaC tool, and you’re not funding the company that relicensed the project you depend on.
For smaller teams or those just starting out, self-managed state backends (S3 + DynamoDB locking for AWS, GCS for GCP) work fine. You only need a platform like Spacelift or env0 when you have multiple teams, need policy enforcement, or want audit trails for every infrastructure change.
What to Learn in 2026
The IaC space has more options than ever, which makes the “what should I actually learn” question harder. Here’s a practical breakdown based on where you are.
New to IaC entirely: Start with OpenTofu + Ansible. OpenTofu handles provisioning (creating cloud resources), Ansible handles configuration (setting up what’s on those resources). This combination covers 90% of infrastructure automation needs and both tools have large communities, extensive documentation, and strong job markets.
Platform engineering teams: Add Crossplane to your stack. If you’re building an internal developer platform on Kubernetes, Crossplane gives application teams self-service infrastructure through the Kubernetes API they already know. Pair it with Backstage for the developer portal layer.
Already on Terraform: You don’t need to migrate tomorrow. Terraform works, the provider ecosystem is unmatched, and your existing code runs fine. But test OpenTofu with your next greenfield project. The migration is painless, and you’ll appreciate native state encryption.
Software engineers writing IaC: Look at Pulumi. If you’re a developer who was handed infrastructure responsibilities and HCL feels alien, Pulumi lets you stay in Python or TypeScript. The CDKTF deprecation removed the only real competitor in this space.
CI/CD modernization: Evaluate Dagger for complex pipelines. If your team spends more time debugging CI configurations than writing application code, Dagger’s “pipelines as real code” approach pays off. Keep YAML for simple workflows.
Container runtime: Docker remains the standard, but add Podman to your skillset. RHEL-family distributions ship Podman by default, and knowing both runtimes makes you more versatile. The commands are nearly identical, so the learning curve is minimal.
The tools that dominated five years ago (Chef, Puppet, Vagrant) are winding down. The tools gaining momentum (OpenTofu, Crossplane, Pulumi, Dagger) are where the industry is heading. Place your bets accordingly.