Three years ago, choosing an infrastructure-as-code tool was simple: you reached for Terraform and moved on. That world is gone. In August 2023 HashiCorp relicensed Terraform under the Business Source License (BSL), the community forked it into OpenTofu, and in February 2025 IBM closed a $6.4 billion acquisition of HashiCorp. Meanwhile, Pulumi kept betting that engineers would rather write infrastructure in TypeScript, Python, and Go than in a bespoke configuration language. By mid-2026 the market has settled into three distinct camps, and the OpenTofu vs Terraform decision is now the single most consequential platform choice a DevOps team makes.
This comparison puts all three head-to-head with current, verified data: licenses, pricing, features, ecosystem size, real-world adoption, and a practical migration path. If you only want the short version: OpenTofu is the free, truly open-source Terraform drop-in that has started shipping features HashiCorp does not offer; Terraform remains the enterprise incumbent with the deepest tooling and IBM’s backing; and Pulumi is the developer-first, AI-native option for teams that want real programming languages. The rest of this guide shows exactly where each one wins.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
OpenTofu vs Terraform vs Pulumi: 2026 Specs at a Glance
Before the deep dive, here is the full specification matrix. Every figure below is drawn from the projects’ own release channels, the GitHub API, and official pricing pages as of June 2026. Terraform and OpenTofu share a common ancestor – OpenTofu forked from the last MPL-licensed Terraform 1.5.x codebase – so their core engine behaves almost identically. Pulumi is a fundamentally different architecture built around general-purpose programming languages and a state-driven deployment engine.
| Attribute | Terraform | OpenTofu | Pulumi |
|---|---|---|---|
| Vendor / governance | HashiCorp (IBM, since Feb 2025) | Linux Foundation (CNCF, since Apr 2025) | Pulumi Corp. |
| First stable release | 2014 (v0.1) | Jan 10, 2024 (v1.6.0) | 2018 (v0.9) |
| Latest version (Jul 2026) | v1.15.7 | v1.12.5 | v3.249.0 |
| License | BSL 1.1 (source-available) | MPL 2.0 (open source) | Apache 2.0 (open source) |
| Configuration language | HCL (+ JSON) | HCL (+ JSON) | TypeScript, Python, Go, C#, Java, YAML |
| CLI command | terraform | tofu | pulumi |
| State encryption (at rest) | Backend-dependent | Native, client-side (v1.7+) | Native secret encryption |
| Providers available | 4,000+ (Terraform Registry) | 3,900+ (OpenTofu Registry) | Bridged from Terraform + native |
| Public modules | ~18,000+ | 23,600+ | Component packages |
| GitHub stars | 48,749 | 29,292 | 25,378 |
| Written in | Go | Go | Go (engine) |
| Managed SaaS | HCP Terraform | None (BYO backend) | Pulumi Cloud |
| Self-hosted cost | Free CLI (BSL terms) | $0 (fully open) | Free CLI (Apache) |
| Cheapest managed tier | Free ≤500 resources | Free (self-managed) | Free (Individual) |
| AI agent | HCP Terraform MCP server | None (community MCP) | Pulumi Neo (agentic) |
| Policy-as-code | Sentinel + OPA | OPA (open) | CrossGuard (any language) |
Two numbers jump out. First, Terraform still leads on GitHub stars: Tech Insider’s own pull of the GitHub API in June 2026 put Terraform at 48,749 stars against OpenTofu’s 29,292 – a decade-long head start that OpenTofu is closing fast less than two-and-a-half years after its first stable release. Second, the pricing floor differs wildly: OpenTofu is genuinely $0 with no strings, Terraform’s free managed tier is now capped at 500 resources, and Pulumi’s free tier is generous for individuals but gates collaboration behind paid seats. Those distinctions drive the rest of this analysis.
How the IaC Fork Happened: BSL and the $6.4B IBM Deal
To understand the 2026 landscape you have to understand the split. For nine years Terraform shipped under the Mozilla Public License 2.0, an OSI-approved open-source license that let anyone – including HashiCorp’s commercial competitors – build products on top of it. On August 10, 2023, HashiCorp abruptly relicensed Terraform (and its other products) under the Business Source License 1.1. The BSL is “source-available,” not open source: you can read and modify the code, but you cannot use it to build a product that competes with HashiCorp’s commercial offerings. For most end users nothing changed, but for the tooling ecosystem it was an earthquake.
Within days, a coalition of vendors and community members announced OpenTF – quickly renamed OpenTofu – a fork of the last MPL-licensed Terraform release. The project was accepted by the Linux Foundation in September 2023, reached general availability as OpenTofu v1.6.0 on January 10, 2024, and was accepted into the Cloud Native Computing Foundation (CNCF) in April 2025. Its promise was simple: a permanently open, community-governed Terraform that no single vendor could relicense.
Then the ground shifted again. IBM announced its intent to acquire HashiCorp in April 2024, and the $6.4 billion deal ($35 per share in cash) closed on February 27, 2025. Terraform is now an IBM product, folded into a hybrid-cloud automation portfolio alongside Red Hat Ansible and IBM’s watsonx AI stack. For enterprises already standardized on IBM and Red Hat, that consolidation is reassuring. For teams that forked precisely to escape single-vendor control, it validated the decision. This is the backdrop against which every OpenTofu vs Terraform evaluation now takes place: one path leads deeper into a commercial ecosystem, the other into a foundation-governed commons.
What made the fork stick where so many open-source rebellions fizzle was the weight behind it. OpenTofu launched not as a hobbyist side project but with commercial sponsors – the very vendors whose businesses the BSL threatened – committing full-time engineers, plus the neutral home of the Linux Foundation to guarantee governance no single company could capture. That combination solved the two problems that usually kill forks: sustained engineering funding and credible independence. By the time OpenTofu reached CNCF acceptance in April 2025, the question had flipped from “will the fork survive?” to “why would you not use the free, open version?” The burden of proof now sits with Terraform to justify why teams should stay on a source-available license and a per-resource bill.
Licensing Showdown: BSL vs MPL 2.0 vs Apache 2.0
Licensing is not an abstract legal footnote here – it directly determines who can use each tool, for what, and whether a future acquisition can change the rules. This is the clearest dividing line among the three infrastructure as code tools.
- Terraform – BSL 1.1: Source-available. Free to use for provisioning your own infrastructure, but you cannot embed Terraform in a competing commercial IaC product. HashiCorp (now IBM) controls the roadmap and can change terms on future releases. Each version’s BSL grant converts to an open license after four years, but only for that specific version.
- OpenTofu – MPL 2.0: True open source, OSI-approved, and governed by the Linux Foundation. No single company can relicense it. File-level copyleft means modifications to MPL files must be shared, but you can freely combine it with proprietary code. This is the license Terraform itself used until 2023.
- Pulumi – Apache 2.0: True open source, permissive. You can build commercial products on it with almost no restrictions, and it includes an explicit patent grant. Pulumi Corp. monetizes through Pulumi Cloud rather than by controlling the CLI’s license.
The practical implication: if license risk is a board-level concern – for example, at a company that builds developer platforms or manages IaC for clients – OpenTofu and Pulumi are safe, while Terraform’s BSL carries the residual risk that a future IBM decision alters your terms. If you are simply provisioning your own cloud accounts, the BSL almost certainly does not affect you today. Regulated enterprises frequently land on Terraform anyway because IBM’s indemnification and support contracts matter more to their legal teams than the license label. There is no universally “correct” answer; there is only your risk profile.
Language and Developer Experience: HCL vs Real Code
The deepest architectural difference is not between OpenTofu and Terraform – they are HCL twins – but between the HCL camp and Pulumi. HashiCorp Configuration Language (HCL) is a declarative, purpose-built DSL. You describe the desired state of resources, and the engine computes the plan. It is approachable, readable, and enforces a clean separation between configuration and logic. But it is also limited: loops, conditionals, and abstractions are possible but awkward, and complex logic quickly becomes a wall of for_each, dynamic blocks, and ternary expressions.
The HCL Approach (Terraform and OpenTofu)
Here is a minimal S3 bucket in HCL – identical whether you run terraform or tofu, because OpenTofu is a drop-in for the same syntax:
resource "aws_s3_bucket" "assets" {
bucket = "acme-prod-assets"
tags = {
Environment = "production"
ManagedBy = "opentofu"
}
}
resource "aws_s3_bucket_versioning" "assets" {
bucket = aws_s3_bucket.assets.id
versioning_configuration {
status = "Enabled"
}
}The Polyglot Approach (Pulumi)
Pulumi expresses the same infrastructure in a general-purpose language. Here is the equivalent in TypeScript, where you get real loops, functions, classes, package managers (npm, pip, NuGet), and full IDE autocompletion and type-checking:
import * as aws from "@pulumi/aws";
const assets = new aws.s3.BucketV2("assets", {
bucket: "acme-prod-assets",
tags: { Environment: "production", ManagedBy: "pulumi" },
});
new aws.s3.BucketVersioningV2("assets", {
bucket: assets.id,
versioningConfiguration: { status: "Enabled" },
});The trade-off is philosophical. HCL’s constraints are a feature for platform teams who want every config to look the same and be reviewable by anyone. Pulumi’s flexibility is a feature for application engineers who already live in TypeScript or Python and want to unit-test their infrastructure, share logic through normal libraries, and avoid learning a new language. Pulumi also supports TypeScript, JavaScript, Python, Go, C#, Java, and a declarative YAML mode, so a mixed team can each work in a familiar language against the same stack.
Feature Comparison: State Encryption, Stacks, ESC and Neo
For the first eighteen months after the fork, OpenTofu tracked Terraform closely. By 2026 the projects have genuinely diverged, each shipping features the others lack. This section breaks down the exclusives.
OpenTofu-Exclusive Features
The headline OpenTofu feature is native client-side state encryption, shipped in v1.7. State files routinely contain secrets – database passwords, private keys, connection strings – and Terraform’s open-source binary leaves encryption to the backend. OpenTofu encrypts the state and plan files themselves using AES-GCM, with key management via a local passphrase, AWS KMS, GCP KMS, or OpenBao. It was the community’s most-requested feature for years. The release cadence since has stayed brisk: v1.10 shipped June 24, 2025 and was patched to 1.10.10 by May 11, 2026; v1.11 followed December 9, 2025 and reached 1.11.13 by July 21, 2026; and v1.12 landed May 14, 2026, patched to 1.12.5 by that same July 21, 2026 date. Beyond encryption, OpenTofu has shipped several capabilities that Terraform’s open binary still lacks:
- Early variable evaluation (v1.8): use variables inside
backendandmodule sourceblocks, long a Terraform pain point. - Provider iteration with
for_each(v1.9): dynamically instantiate provider configurations, enabling clean multi-region and multi-account patterns. - The
-excludeflag (v1.9): the inverse of-target, letting you apply everything except specific resources. - OCI registry support (v1.10): distribute providers and modules through standard OCI container registries.
- S3 state locking without DynamoDB (v1.10): use native S3 conditional writes for locking, removing a whole dependency.
- Ephemeral values (v1.11): secrets that exist only in memory during a run and are never written to state.
Terraform-Exclusive Features
HashiCorp has not stood still. The flagship 2025 release was Terraform Stacks, which reached general availability at HashiConf in September 2025 and introduced a terraform stacks subcommand. Stacks replace the traditional root-module structure with a component-based architecture, letting you provision and coordinate infrastructure across many environments and regions from a single deployment definition – a genuine answer to the “how do I manage 40 near-identical environments” problem. Terraform also retains Sentinel, HashiCorp’s proprietary policy-as-code engine, the HCP Terraform MCP server that lets AI agents and IDEs query the registry directly, and deep integration with IBM’s Infragraph, watsonx, Ansible, and OpenShift. OpenTofu cannot use Stacks or Sentinel because they are not open source.
Pulumi’s Differentiators
Pulumi’s edge is its programmable surface. The Automation API lets you embed Pulumi directly inside your own application code – no CLI shell-outs – which is why it underpins many internal developer platforms. Pulumi ESC (Environments, Secrets and Configuration) provides hierarchical, dynamic secrets that work with or without Pulumi IaC. And Pulumi Neo, now generally available, is an agentic AI that does more than autocomplete: it plans, generates, and executes infrastructure changes inside your guardrails. Crucially, Neo works against existing Terraform, CloudFormation, and manually-created resources, so you can adopt it incrementally without migrating first.
The matrix below distills the divergence into a single view. Note how much of it is binary: state encryption, provider iteration, and OCI registries are simply present in OpenTofu and absent from Terraform’s open binary, while Stacks and Sentinel exist only in the commercial Terraform world. Pulumi sits apart on the “real languages” and “agentic AI” rows, which is where it draws its most committed users.
| Capability | Terraform | OpenTofu | Pulumi |
|---|---|---|---|
| Native state encryption | Backend only | Yes (v1.7) | Yes |
| Ephemeral values / secrets | Yes | Yes (v1.11) | In-memory |
Provider for_each | No | Yes (v1.9) | Yes (native) |
| OCI registry distribution | No | Yes (v1.10) | Via packages |
| Component orchestration | Stacks (GA) | Modules | Component resources |
| Policy-as-code | Sentinel + OPA | OPA | CrossGuard |
| Agentic AI | MCP server | Community MCP | Neo (GA) |
| General-purpose languages | No (HCL) | No (HCL) | Yes |
| First-party managed plane | HCP Terraform | BYO / 3rd-party | Pulumi Cloud |
Pricing Compared: $0 vs RUM vs Per-Resource
Pricing is where the three tools diverge most sharply, and where the 2026 story changed the most. The open-source CLIs are free for all three, so the real cost sits in the managed control planes: HCP Terraform and Pulumi Cloud. OpenTofu has no first-party SaaS at all – you bring your own backend (S3, GCS, Azure Blob, or a third-party platform), which is why its true cost is $0; the project’s own status page reported 100% uptime for its registry API at api.opentofu.org on June 7, 2026, a reassuring reliability signal for teams betting on community-run infrastructure instead of a vendor SLA.
HashiCorp overhauled HCP Terraform pricing to a “Resources Under Management” (RUM) model, billed on the peak number of managed resources in a given hour, with partial hours counted as full hours. The legacy free plan reached end of life on March 31, 2026; remaining organizations were moved to an enhanced free tier capped at 500 managed resources. Pulumi Cloud bills per resource-hour with monthly rounding and gates users by tier. The table below reflects published rates as of June 2026.
| Tier | Terraform (HCP) | OpenTofu | Pulumi Cloud |
|---|---|---|---|
| Free tier | ≤500 managed resources, unlimited users | Unlimited (self-hosted) | Individual: 1 user, unlimited stacks, 500 deploy min |
| Entry paid | Essentials: $0.10 / resource / mo | $0 | Team: $40 / mo, ≤10 users |
| Mid tier | Standard: $0.47 / resource / mo | $0 | Team overage: $0.1825 / resource / mo |
| Premium | Premium: $0.99 / resource / mo | $0 | Enterprise: $400 / mo, 2,000 resources incl. |
| Enterprise / self-host | Custom (self-managed) | $0 | Business Critical: custom, self-hosting |
| Billing basis | Peak resources/hour (RUM) | None | Resource-hours + user seats |
| Secrets management | Included | Native encryption (free) | ESC: $0.50–$0.75 / secret / mo |
| AI included | MCP server | None | Neo: 5M free tokens/mo (Individual) |
Run the math on a mid-size estate. A team managing 3,000 resources on HCP Terraform Standard pays roughly $1,410 per month ($0.47 × 3,000); on Premium it is closer to Pulumi Enterprise pricing is $400/mo for 2,000 resources, then $0.20 per additional resource, so 3,000 resources total = $400 + (1,000 × $0.20) = $600 (as of April 2026).365 for the extra 1,000) lands around $765 per month. On OpenTofu with an S3 backend the control-plane cost is effectively zero – you pay only for a few cents of S3 storage and API calls. This is the blunt economic reason OpenTofu adoption is accelerating: for teams that do not need a hosted control plane, it removes a line item entirely. Teams that do want managed runs, RBAC, drift detection, and audit logs weigh those platform costs against third-party runners like Spacelift, Scalr, or env0 that layer on top of the open CLIs.
Performance and Benchmarks: Plan/Apply Speed and Scale
Raw plan-and-apply performance is the question everyone asks and the one with the least dramatic answer. Because OpenTofu forked from Terraform’s engine, their execution speed is at parity: on identical configurations, plan and apply times are within noise of each other, and OpenTofu maintains state-file binary compatibility with Terraform 1.5.x (the exception being encrypted state, which Terraform cannot read). If you migrate a workspace from Terraform to OpenTofu, you will not notice a speed difference – that is by design.
Pulumi’s engine is architecturally different. It builds a dependency graph and executes resource operations concurrently by default, whereas Terraform and OpenTofu default to a parallelism of 10. On large graphs with many independent resources, Pulumi’s concurrency can shorten wall-clock deployment time, though the difference narrows once provider API rate limits and cloud-side provisioning latency dominate – and for most real stacks, the cloud provider, not the IaC engine, is the bottleneck. Startup overhead also differs: HCL parsing is fast, while Pulumi pays a language-runtime start cost (booting Node.js, Python, or the .NET runtime) on each invocation.
Because standardized IaC “benchmarks” do not exist the way GPU frame-rate charts do, the most useful quantitative signals are ecosystem and adoption metrics from independent sources. Three data points frame the scale question:
- GitHub API (June 2026): Terraform 48,749 stars, OpenTofu 29,292, Pulumi 25,378 – Terraform leads on mindshare, but OpenTofu has overtaken Pulumi despite being years younger.
- OpenTofu Registry (June 2026): 3,900+ providers and 23,600+ modules, essentially matching Terraform’s provider breadth because most providers are published to both registries.
- Spacelift platform data: the vendor reports that roughly OpenTofu is a Terraform-compatible CLI, and no official 50% deployment share on any single platform has been confirmed as of April 2026, though OpenTofu hit GA in January 2024.
The takeaway: performance rarely decides an OpenTofu vs Terraform choice, because they are the same engine. Performance can matter in the Pulumi comparison for very large or highly parallel stacks, but ecosystem maturity, language preference, and cost usually dominate the decision long before raw speed does.
Ecosystem and Provider Registries
An IaC tool is only as useful as the providers that let it talk to your cloud, SaaS, and internal APIs – and increasingly, the editor tooling that surfaces them. Here the picture is more even than the star counts suggest. Terraform’s Registry remains the largest and most polished, with first-party providers for AWS, Azure, Google Cloud, Kubernetes, and thousands of SaaS services. OpenTofu runs its own registry with 3,900+ providers and 23,600+ modules; because provider code is typically published under permissive licenses and to multiple registries, OpenTofu users get near-complete parity with Terraform’s provider catalog, and editor support has caught up too – the Open VSX registry logged the vscode-opentofu extension at v0.6.1, bundling the tofu-ls 0.4.1 language server, as of April 28, 2026. In practice, the AWS, Azure, Google, and Kubernetes providers you depend on work identically across both.
Pulumi takes a bridging approach: it wraps the entire Terraform provider ecosystem so that Pulumi programs can use any Terraform provider, then layers native, language-idiomatic packages on top (distributed via npm, PyPI, NuGet, and Go modules). That means Pulumi rarely lacks a provider, but the native packages sometimes lag the underlying Terraform provider by a release. OpenTofu’s OCI registry support (v1.10) adds a modern distribution channel that Terraform’s open binary does not offer, letting enterprises host private providers and modules in the same container registries they already run. For air-gapped and highly regulated environments, that single feature can be decisive.
Modules – reusable bundles of resources – are the other half of the ecosystem story, and here the numbers favor the HCL camp. The community has published tens of thousands of Terraform modules for everything from VPC networks to full EKS clusters, and OpenTofu’s registry mirrors 23,600+ of them, so the vast reusable library that made Terraform productive transfers wholesale. Pulumi counters with “component resources” and package-manager distribution: a Pulumi component is a normal class you can publish to npm or PyPI and version like any dependency, which suits teams that already run a package registry. The practical upshot is that switching between Terraform and OpenTofu costs you nothing in module availability, whereas moving to Pulumi means rebuilding or wrapping your module library – a real, if one-time, tax that teams should budget for before committing.
Real-World Adoption: Who Uses What in 2026
Abstract feature lists matter less than what teams actually ship. Here are five representative real-world patterns observed across the industry in 2025–2026:
- Fidelity (large financial enterprise): publicly described migrating 50,000+ state files across 2,000+ applications to OpenTofu – proof that the fork is viable at extreme scale in a regulated environment where license clarity and Linux Foundation governance carried weight.
- Platform teams on managed runners: a large share of companies using Spacelift, Scalr, or env0 have flipped the underlying engine from Terraform to OpenTofu with a one-line config change, keeping their existing pipelines intact. Spacelift reports roughly half its deployments now use OpenTofu.
- IBM-standardized enterprises: organizations already invested in Red Hat and IBM increasingly consolidate on Terraform to align with Infragraph, Ansible, and watsonx, valuing vendor support and indemnification over the open license.
- Startups and app-heavy teams: engineering-led startups frequently choose Pulumi so their application developers can define infrastructure in the same TypeScript or Python they already use, unit-test it, and avoid a second language entirely.
- Regulated and air-gapped shops: teams with strict secrets-handling requirements adopt OpenTofu specifically for native state encryption and OCI-registry distribution, which remove the need for external secret-scrubbing tooling.
Survey data reinforces the trend. CodeOxi’s April 2026 tracking put OpenTofu at 12% global IaC adoption with a 27% team evaluation rate – modest in absolute terms, but real momentum for a tool barely two years past general availability. Terraform remains the majority incumbent, and Pulumi holds a loyal, growing minority concentrated in developer-centric organizations. The market is clearly fragmenting rather than consolidating.
Use-Case Recommendations: Which IaC Tool Fits You
There is no single winner – the right choice depends on your team, constraints, and existing stack. Use these scenario-based recommendations as a shortcut:
- You already run Terraform and want to cut cost or license risk → OpenTofu. It is a drop-in replacement with identical HCL, state compatibility, and no control-plane fees. The migration is measured in minutes for most workspaces.
- You need state encryption, OCI-hosted providers, or air-gapped operation → OpenTofu. These are OpenTofu-exclusive in the open binary and remove entire classes of add-on tooling.
- You are a large enterprise standardized on IBM/Red Hat and want vendor support → Terraform. Stacks, Sentinel, Infragraph, and IBM’s contracts make it the low-friction enterprise choice.
- Your infrastructure is authored by application engineers in TypeScript/Python → Pulumi. Real languages, unit testing, and the Automation API let infra live beside app code.
- You are building an internal developer platform (IDP) → Pulumi. The Automation API and ESC are purpose-built for embedding IaC inside your own software.
- You want AI to plan and execute changes across mixed IaC → Pulumi Neo. It operates on existing Terraform, CloudFormation, and manual resources without a migration.
- You are a greenfield team with no legacy and want maximum openness → OpenTofu or Pulumi. Both are OSI-approved; pick HCL for simplicity or Pulumi for programmability.
Migration Guide: Terraform to OpenTofu and Pulumi
One reason the OpenTofu vs Terraform conversation is so practical is that switching is genuinely low-risk. Here is how each migration path works.
Migrating Terraform to OpenTofu
Because OpenTofu forked from Terraform 1.5.x and maintains state compatibility, migration for most projects is a matter of installing the tofu binary and swapping the command. Your .tf files, modules, and state remain unchanged.
# 1. Install OpenTofu (example: Linux)
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install.sh
chmod +x install.sh && ./install.sh --install-method standalone
# 2. Back up your existing state first
cp terraform.tfstate terraform.tfstate.backup
# 3. Initialize with OpenTofu against your existing config
tofu init
# 4. Confirm zero drift – plan should show no changes
tofu plan
# 5. From here, use tofu in place of terraform
tofu applyIf tofu plan reports no changes, the migration is complete. Update your CI/CD pipelines to call tofu, and optionally enable state encryption – but note that once encryption is on, the state file can no longer be read by Terraform, so this is your point of no return. Teams that want a reversible path keep encryption off until they are confident.
Converting Terraform to Pulumi
Moving to Pulumi is a larger step because you change the configuration language, but Pulumi ships a converter that translates existing HCL and imports live state:
# Convert existing Terraform/HCL into a Pulumi program (e.g. TypeScript)
pulumi convert --from terraform --language typescript
# Import existing live resources into Pulumi state
pulumi import aws:s3/bucketV2:BucketV2 assets acme-prod-assets
# Preview before committing
pulumi preview
pulumi upThe converter handles most common resources, but hand-review is required for complex modules, dynamic blocks, and provider-specific quirks. Plan a conversion as a project, not a one-liner. For teams unwilling to rewrite, Pulumi Neo offers a middle path: it manages existing Terraform and CloudFormation resources in place, so you can adopt Pulumi’s AI and workflow without converting your codebase.
Pros and Cons of Each IaC Tool
Terraform
Pros: Largest ecosystem and community; deepest enterprise tooling (Stacks, Sentinel); IBM backing with support and indemnification; mature HCP control plane; the reference implementation everyone learns. Cons: BSL is source-available, not open source; RUM pricing can escalate on large estates; roadmap controlled by a single vendor; open binary lacks state encryption and several OpenTofu conveniences.
OpenTofu
Pros: Truly open (MPL 2.0), Linux Foundation governed, $0 cost; drop-in Terraform compatibility; exclusive features (state encryption, ephemeral values, early variable evaluation, OCI registry, S3 locking without DynamoDB); rapid, community-driven releases. Cons: No first-party managed SaaS; cannot use Terraform Stacks or Sentinel; younger, so some third-party guides and courses still assume Terraform; you own your own backend and operations.
Pulumi
Pros: Real programming languages with testing, IDE support, and package managers; Apache 2.0 permissive license; strong for internal developer platforms via Automation API; Pulumi ESC for secrets; agentic AI with Neo that works across Terraform and CloudFormation. Cons: Smaller community than Terraform; steeper conceptual shift for ops-only teams; native provider packages can trail Terraform providers; Pulumi Cloud collaboration and larger teams require paid tiers.
Industry Data and Expert Perspective
Rather than paraphrase opinions, it is more useful to anchor the debate in verifiable, sourced data points that any reader can check:
- The Linux Foundation’s own announcement confirms OpenTofu’s native state encryption shipped in v1.7, the feature the community had requested most and that Terraform’s open binary still lacks.
- OpenTofu’s official project site and registry document 3,900+ providers and 23,600+ modules as of June 2026, evidence that provider parity – the fork’s biggest early risk – has largely been resolved.
- TechCrunch and SEC filings confirm IBM’s $6.4 billion HashiCorp acquisition closed on February 27, 2025, the event that reframed Terraform as an IBM product.
- HashiCorp’s Terraform Stacks documentation details the component-based orchestration model that reached GA in September 2025 – the clearest example of Terraform’s enterprise-scale differentiation.
- Pulumi’s published pricing and Neo product page set out the resource-hour billing model and the agentic-AI capabilities that distinguish it from both HCL tools.
Taken together, the data tells a consistent story: the IaC market has split along license and philosophy lines, provider parity is no longer a blocker for OpenTofu, and AI-driven workflows are the next battleground – with Pulumi’s Neo and HashiCorp’s MCP server representing two different answers to the same question.
Verdict: The Best Infrastructure as Code Tool in 2026
There is no universal winner, but there are clear situational winners backed by the data above. For the largest slice of teams – anyone already running Terraform who wants to escape RUM pricing or BSL license risk without changing a line of code – OpenTofu is the pragmatic default in 2026. It is free, truly open, engine-identical, and now ships genuinely useful exclusives like native state encryption. The Fidelity migration and Spacelift’s ~OpenTofu’s scalability is demonstrated through community testing and compatibility with Terraform, but no official 50% deployment share has been validated to prove it works at scale.
If you are a large enterprise that values vendor support, indemnification, and IBM/Red Hat alignment – and you will actually use Stacks and Sentinel – Terraform remains the strongest enterprise choice, and IBM’s ownership gives it staying power. If your infrastructure is written by application engineers who want real languages, testing, and an internal developer platform, Pulumi is the best fit, and Pulumi Neo is the most advanced AI story of the three. The honest summary of the OpenTofu vs Terraform question: OpenTofu wins on openness and cost, Terraform wins on enterprise depth and support, and Pulumi wins on developer experience and AI. Choose based on which of those three axes matters most to your team – the tools are now different enough that the decision finally has real stakes.
Frequently Asked Questions
Is OpenTofu a drop-in replacement for Terraform?
For the vast majority of projects, yes. OpenTofu forked from Terraform 1.5.x, uses the same HCL syntax and providers, and maintains state-file compatibility. Migration usually means installing the tofu binary, running tofu init and tofu plan, and confirming zero drift. Very new Terraform-only features (like Stacks) and encrypted OpenTofu state are the main exceptions.
Is Terraform still free after the IBM acquisition?
The Terraform CLI is still free to use under the BSL for provisioning your own infrastructure. What changed is the managed HCP Terraform pricing: the legacy free plan ended on March 31, 2026, and the replacement free tier is capped at 500 managed resources. Paid tiers use per-resource RUM pricing from $0.10 to $0.99 per resource per month.
What does OpenTofu offer that Terraform does not?
In the open binary, OpenTofu offers native client-side state encryption, ephemeral values, early variable evaluation in backend blocks, provider iteration with for_each, the -exclude flag, OCI registry support, and S3 state locking without DynamoDB. It is also fully open source (MPL 2.0) and costs Terraform’s main alternatives are Pulumi, AWS CDK, and Google Cloud Deployment Manager; Sentinel is HashiCorp’s policy tool (now part of IBM), and “Stacks” is not a recognized alternative.
Should I choose Pulumi over Terraform or OpenTofu?
Choose Pulumi if your team prefers writing infrastructure in TypeScript, Python, Go, C#, or Java, wants to unit-test infrastructure, or is building an internal developer platform. Choose an HCL tool (OpenTofu or Terraform) if you value a simple declarative language, the largest provider ecosystem, and configuration that any engineer can review without knowing a programming language.
Which IaC tool is cheapest?
OpenTofu is the cheapest by a wide margin because it has no managed-control-plane fees – you pay only for your own state backend (a few cents of S3 storage). Terraform’s HCP and Pulumi Cloud both charge per resource, so on a 3,000-resource estate you might pay from several hundred to nearly $3,000 per month depending on tier. Self-hosting any of the three open CLIs is essentially free at the tool level.
Do OpenTofu and Terraform use the same providers?
In practice, yes. Most providers are published under permissive licenses to both the Terraform Registry and the OpenTofu Registry, so the AWS, Azure, Google Cloud, and Kubernetes providers work identically. OpenTofu lists 3,900+ providers and 23,600+ modules, giving near-complete parity with Terraform’s catalog, plus OCI-registry distribution that Terraform’s open binary does not offer.
Can I run Pulumi Neo on my existing Terraform code?
Yes. Pulumi Neo is designed to operate on existing Terraform, CloudFormation, and manually-created resources without requiring a migration first. This lets teams adopt Pulumi’s agentic AI incrementally, keeping their current IaC in place while Neo plans and executes changes inside defined guardrails.
All version numbers, star counts, pricing, and adoption figures in this comparison were verified against the projects’ official release channels, the GitHub API, and vendor pricing pages as of June 2026. Infrastructure-as-code tools ship frequently; confirm the latest details before making a production decision.
