The best open source infrastructure as code tools in 2026

★ 49,995GoNOASSERTIONupdated Oct 2026

best for teams on AWS, GCP, or Azure who want the deepest provider ecosystem and don't mind HashiCorp's license

Terraform's provider ecosystem is deeper than OpenTofu's, Pulumi's, or Crossplane's — if a cloud or SaaS has an API, there's almost certainly a maintained provider for it already. The plan-before-apply workflow produces a diff clear enough that someone who didn't write the config can review it in a pull request, and the resource graph handles parallel execution across hundreds of resources without you having to think about ordering.

HashiCorp moved the license to the Business Source License in 2023, so this isn't open source in the strict sense — that's the entire reason OpenTofu exists, and it's worth knowing before a team commits to it. HCL shows its age once config needs real logic: for expressions and dynamic blocks do things that would be a few lines in any general-purpose language. State stays a single file that needs an external lock, such as DynamoDB or a blob container, to be safe with more than one person touching it, and Terraform only notices infrastructure drift when someone remembers to run a plan.

Our full take →GitHub ↗

★ 30,560GoMPL-2.0updated Oct 2026

best for teams that want Terraform's workflow without committing to the BSL license

OpenTofu reads your existing .tf files, works with the same providers, and opens the same state files Terraform does, so moving over costs close to nothing. It's a CNCF project now, with a published charter and a technical steering committee, which gives it more protection against another relicensing than most forks have. Beyond parity it's shipped things Terraform hasn't: native state encryption, early variable evaluation, and OCI registry support for modules.

It still carries Terraform's internal complexity — the plugin protocol alone spans more than twenty versioned proto files — and hasn't had the years needed to clean that up. Its provider ecosystem is really Terraform's: OpenTofu mirrors the Terraform registry rather than building its own, so if HashiCorp ever restricted provider licensing to lock out forks, OpenTofu would feel it immediately. State management hasn't moved past Terraform's single-file model either, so the same external-locking requirement applies here too.

Our full take →GitHub ↗

★ 25,799GoApache-2.0updated Oct 2026

best for teams that would rather write infrastructure in TypeScript, Python, Go, C#, or Java than HCL

Pulumi lets you write infrastructure in TypeScript, Python, Go, C#, or Java instead of wrestling with HCL, which matters the moment your config needs a loop, a class, or a package from your normal ecosystem rather than a for expression. Its Automation API goes further than anything Terraform or OpenTofu offer — you can drive Pulumi from your own process, which is how teams build self-service infra portals or automated test teardown. Its 300-plus providers exist because most are generated from Terraform's providers through a bridge, so coverage keeps pace with Terraform's without someone hand-writing each one.

That bridge is also the weak point: Pulumi inherits whatever bugs and quirks sit in the underlying Terraform provider, since it isn't designing its own resource model. Large stacks feel slower to apply than they do in Terraform or OpenTofu, because every operation round-trips through a gRPC connection between the CLI and your language runtime. State storage defaults toward Pulumi Cloud, their own SaaS, and teams that don't deliberately set up a self-hosted backend end up depending on it. Cross-stack references can also create ordering dependencies that aren't visible anywhere in the code, which turns into a hard circular-reference error to track down.

Our full take →GitHub ↗

★ 12,186GoApache-2.0updated Oct 2026

best for platform teams building an internal developer platform on Kubernetes

Crossplane doesn't compete with Terraform, OpenTofu, or Pulumi so much as sit a layer above them — it turns cloud resources into Kubernetes CRDs so a platform team can expose a simplified, organization-defined API to the rest of engineering. The composition functions model is a real escape hatch from the old patch-and-transform system: you write actual logic, in any language, as a function in the pipeline instead of forking the core project. Providers, functions, and configurations all ship as versioned, signed OCI images, so dependency management looks like container image management rather than a bespoke registry.

The learning curve is steep before any of that pays off — XRDs, XRs, Claims, Compositions, Functions, and Providers all need to click before a new team member can do anything, and that takes days, not hours. A non-trivial AWS setup can mean ten or more provider pods, each with its own CRDs and RBAC, which puts real pressure on the API server at scale. When a composite resource gets stuck, the error usually isn't on the XR's status — it's buried in a provider pod's logs or a function runner's logs, so debugging means cross-referencing several objects instead of reading one clear message. Teams still on v1.x face a real migration gap, since the v2 composition and XRD changes are ahead of where the tooling and documentation currently are.

Our full take →GitHub ↗