Every infrastructure team that touches AWS, Azure, GCP, or Kubernetes eventually hits the same fork in the road: which tool actually defines the cloud resources. For a decade the answer was almost automatic — Terraform. That’s no longer true in 2026. HashiCorp’s Business Source License, IBM’s acquisition of HashiCorp, and two years of OpenTofu’s Linux Foundation-backed development have split the infrastructure-as-code market into three real contenders: Terraform, OpenTofu, and Pulumi. Each one now has a distinct license, a distinct pricing model, and a distinct answer to the question of who should be writing your cloud config in September 2026.
This comparison breaks down the three platforms on licensing, provider coverage, performance, pricing, and migration cost, using the versions shipping this year: Terraform 1.9-1.15 under HashiCorp/IBM’s BSL 1.1, OpenTofu 1.8-1.12 under the Linux Foundation’s MPL 2.0, and Pulumi 3.x under Apache 2.0. If you’re deciding what to standardize on for new cloud projects, or whether it’s finally time to move off Terraform, the data below should settle most of the argument.
Why the IaC market split in the first place
Infrastructure as code stopped being optional years ago. Teams that provision AWS, Azure, or GCP resources by hand in a console lose the audit trail, the peer review, and the repeatability that a declarative config file gives them for free. Terraform became the default answer to that problem starting around 2014, and by 2023 it was the tool most engineers meant when they said “IaC.”
Then HashiCorp switched Terraform’s license from the open source Mozilla Public License to the Business Source License (BSL) 1.1, a move that restricts competitors from building commercial products on top of the Terraform codebase. A group of vendors and maintainers forked the last MPL-licensed release into OpenTofu and handed governance to the Linux Foundation, which keeps the project vendor-neutral by design. Then IBM completed its acquisition of HashiCorp, folding Terraform into IBM’s enterprise software portfolio and answering, for good, the question of whether HashiCorp would ever reverse the license change (it hasn’t, and under IBM ownership it’s less likely than ever).
Pulumi took a different path from day one. Instead of a new declarative language, it lets engineers write infrastructure in TypeScript, Python, Go, C#, or Java, running against the same providers that Terraform and OpenTofu configs point at. That approach was a niche pick for years. In 2026 it looks more prescient, since Pulumi never had a licensing crisis to manage and it’s the option most naturally suited to AI-assisted coding workflows, where an LLM writing real Python is more reliable than one writing HCL blocks.
The result is a three-way market where the “obvious” choice from 2023 is no longer obvious. Terraform vs Pulumi vs OpenTofu is now a real decision, not a formality, and getting it wrong costs a team a multi-day migration later. It also isn’t a purely technical decision anymore. Legal and procurement teams now sit in on tool selection meetings that used to be a pure engineering call, because a license choice made in 2026 can dictate a support contract, an audit trail, or a compliance sign-off years down the line.
Terraform, OpenTofu, and Pulumi: full specs comparison
Here’s how the three platforms stack up on the specs that actually change day-to-day work: licensing, language, provider ecosystem, state handling, and governance.
| Spec | Terraform | OpenTofu | Pulumi |
|---|---|---|---|
| Current version (Sept. 2026) | 1.9–1.15.x | 1.8–1.12.x | 3.x (rolling) |
| License | Business Source License 1.1 | Mozilla Public License 2.0 | Apache 2.0 |
| Governance | HashiCorp / IBM | Linux Foundation | Pulumi Corporation |
| Config language | HCL (declarative) | HCL (declarative) | TypeScript, Python, Go, C#, Java, YAML |
| Provider ecosystem size | 4,800+ providers | Terraform-compatible (same registry) | ~150 native + bridged providers |
| State encryption (built-in) | No (external tools required) | Yes, native | Yes, via Pulumi Cloud or self-managed backends |
| Drop-in Terraform compatibility | N/A | Yes, up to Terraform 1.5 syntax | No (requires rewrite or bridge tooling) |
| Managed SaaS backend | Terraform Cloud | Third-party (e.g. Spacelift, Scalr) | Pulumi Cloud |
| Policy-as-code | Sentinel (paid tiers) | OPA / community tooling | CrossGuard |
| Testing framework | Native terraform test (limited) | Native tofu test | Full unit tests via host language (pytest, Jest, etc.) |
| AI/LLM code generation fit | Moderate (HCL is a DSL, less LLM training data) | Moderate (same HCL constraints) | Strong (general-purpose languages, larger LLM training corpus) |
| Learning curve for existing devs | Medium (new DSL) | Medium (new DSL) | Low if team already knows the host language |
| Enterprise support contracts | Yes, via IBM/HashiCorp | Via third-party partners | Yes, via Pulumi Corporation |
The provider ecosystem gap is the single stat that shows up in nearly every recent IaC comparison: Terraform’s registry lists more than 4,800 providers, covering everything from mainstream clouds to long-tail SaaS APIs. OpenTofu inherits that same registry because it stayed compatible with the pre-BSL Terraform format, so in practice the provider count is a wash between the two. Pulumi’s native and bridged provider count sits closer to 150, which is enough for AWS, Azure, GCP, Kubernetes, and the most common SaaS targets, but it’s a real gap if your team depends on a niche provider that nobody has bridged yet.
Benchmarks: plan and apply speed, memory, drift detection
Licensing debates are easy to argue about. Performance numbers aren’t. A mid-2026 CLI benchmark comparing Terraform 1.9.0, OpenTofu 1.8.0, and Pulumi’s Python runtime on identical infrastructure found meaningful gaps in both speed and memory footprint. OpenTofu came out fastest and lightest on every metric measured, Terraform sat in the middle, and Pulumi’s Python SDK was the slowest to plan and apply but the fastest to detect drift.
| Tool (CLI version) | Plan avg (ms) | Apply avg (ms) | Memory per run (MiB) | Drift detection (min) |
|---|---|---|---|---|
| Terraform 1.9.0 (BSL) | 1,240 | 2,890 | 192 | 11 |
| OpenTofu 1.8.0 | 980 | 2,110 | 168 | 8 |
| Pulumi (Python 3.12 runtime) | 1,560 | 3,120 | 310 | 6 |
Two other benchmark sources back up the general shape of these results even where exact numbers differ. A separate mid-2026 comparison of Terraform 1.14 against OpenTofu 1.11 found OpenTofu consistently faster on plan operations across state files ranging from small (under 50 resources) to large (over 2,000 resources), attributing the gap to Go runtime optimizations merged into OpenTofu that haven’t landed in Terraform. A third writeup focused on state file operations found Pulumi’s overhead concentrated almost entirely in the language runtime startup (Python and Node.js cold starts add real latency compared to a compiled Go binary), not in the underlying provider calls, which is why teams running Pulumi with Go see plan times much closer to Terraform’s.
The practical takeaway: if your CI pipeline runs hundreds of plan/apply cycles a day, OpenTofu’s speed edge compounds into real time saved. If your team already deploys in Python or TypeScript and doesn’t run at that CI volume, Pulumi’s runtime overhead won’t be the bottleneck.
State management: how each tool actually tracks your resources
Every IaC tool needs a source of truth that maps the resources in your cloud account back to the config that created them. That’s what “state” means in this context, and it’s the single most common source of production incidents across all three tools, usually from two people applying against the same state file at the same time and stepping on each other’s changes.
Terraform and OpenTofu both store state as a JSON file, typically in a remote backend like S3, Azure Blob, or Google Cloud Storage, with a locking mechanism (DynamoDB for S3, native locking for the others) to stop concurrent applies from corrupting the file. OpenTofu’s state format stayed compatible with Terraform’s on purpose, which is part of why migrating between the two doesn’t require a state rewrite. The meaningful difference shows up in what happens to that file at rest: OpenTofu added native, built-in encryption for state files, while Terraform still expects teams to bring their own encryption at the storage layer (server-side encryption on the S3 bucket, or a customer-managed KMS key) rather than encrypting the state content itself.
Pulumi’s approach is structurally similar but implemented differently. Its checkpoint files serialize the full resource graph, and Pulumi Cloud encrypts secret values inside that graph by default using a per-stack encryption key, whether the value came from a config secret or was generated as an output during an apply. Self-hosted Pulumi backends (S3, Azure Blob, or a local file) support the same encryption model but require you to manage the key material yourself, which is roughly the same operational burden Terraform users already accept.
Locking behavior is worth checking closely if your team runs a busy CI pipeline with multiple concurrent deploys. Terraform and OpenTofu use the same locking primitives, so teams that already tuned their DynamoDB lock table for Terraform don’t need to touch it after switching to OpenTofu. Pulumi’s locking is handled entirely inside Pulumi Cloud or the self-hosted backend’s native locking, and teams report fewer lock-contention incidents specifically because Pulumi’s default workflow nudges engineers toward smaller, more frequent stack updates instead of one giant apply touching hundreds of resources at once.
State drift, where the real cloud resource no longer matches what the state file records, is a separate problem from locking, and none of the three tools eliminates it. A resource edited by hand in the AWS console, or changed by an auto-scaling policy outside the tool’s control, will drift regardless of whether the state file lives in Terraform Cloud, a self-hosted OpenTofu backend, or Pulumi Cloud. The benchmark numbers earlier in this piece show Pulumi detecting drift fastest among the three, but detection speed only matters if a team has scheduled drift checks running in the first place. A tool advantage on paper doesn’t help a team that never turns the feature on.
Pricing: Terraform Cloud vs Pulumi Cloud vs OpenTofu plus third-party runners
None of the three CLIs cost money to download and run locally. The pricing story is about the managed SaaS layer most teams add on top for remote state, collaboration, and policy enforcement.
| Platform | Free tier | Paid entry price | Billing model |
|---|---|---|---|
| Terraform Cloud | Up to 500 managed resources | ~$0.10/resource/month (Essentials tier) | Per user + resource count |
| Pulumi Cloud | Unlimited for individuals | ~$40/month flat, covering up to 10 users (Team plan) | Per user + resource count |
| OpenTofu + Spacelift (example third-party runner) | Limited free workers | $20,000/year flat, unlimited users (Starter+ plan) | Per user + concurrent workers |
OpenTofu itself is free and has no official first-party SaaS backend, which is both its biggest cost advantage and its biggest operational gap. Teams either self-host state (S3 with DynamoDB locking, or an Azure/GCS equivalent) at effectively zero licensing cost, or they pay a third-party platform like Spacelift, Scalr, or env0 for the collaboration layer that Terraform Cloud and Pulumi Cloud bundle in natively. That third-party dependency is worth weighing: it means OpenTofu’s total cost of ownership depends heavily on which runner you pick, and switching runners later is its own migration project.
On raw per-seat pricing, Terraform Cloud is the cheapest entry point among the two first-party SaaS options. But that comparison undersells the licensing risk baked into the price: paying HashiCorp/IBM for Terraform Cloud commits a team to the BSL long-term, with no guarantee that future price increases or feature gating won’t follow the pattern that triggered the OpenTofu fork in the first place.
Licensing risk, in plain terms
The BSL 1.1 license that HashiCorp put on Terraform in 2023 doesn’t stop most engineering teams from using Terraform for free, including in production and including at commercial companies. What it stops is competitors building and selling a product that directly competes with HashiCorp’s own commercial offerings on top of the Terraform codebase. For the large majority of teams that never planned to resell a Terraform-based SaaS product, the BSL changes nothing about day-to-day usage rights.
What it does change is trust. A license that can be rewritten unilaterally by the vendor once already got rewritten once, and IBM’s acquisition of HashiCorp removes any expectation that a future rewrite is off the table. OpenTofu exists specifically to remove that risk: it’s licensed MPL 2.0, permanently, under Linux Foundation governance that no single company can unilaterally change. Pulumi’s Apache 2.0 license carries the same permanence guarantee, backed by a different governance model (a single vendor, Pulumi Corporation, rather than a foundation), which is a smaller but real difference if vendor-neutrality specifically is the concern.
For teams with IBM enterprise agreements already in place, Terraform under IBM ownership may actually simplify procurement and support contracts, since it folds into an existing vendor relationship rather than adding a new one. For teams with no IBM relationship and no reason to start one, that argument doesn’t apply, and the license-risk calculus tilts toward OpenTofu or Pulumi.
Real-world use cases: who picks what and why
The abstract licensing and performance arguments matter less than how teams with real constraints are actually choosing. Here are five scenarios that map cleanly to one of the three tools.
- Large enterprise already on an IBM contract. A regulated financial services company running IBM Cloud Pak and other IBM enterprise software has procurement, support SLAs, and security review processes already built around IBM vendor relationships. Staying on Terraform under IBM ownership avoids opening a new vendor review for OpenTofu or Pulumi, even though the raw tooling capability is comparable.
- Open-source-first infrastructure team with existing Terraform modules. A mid-size SaaS company with two years of Terraform HCL already written doesn’t want to rewrite thousands of lines of config. OpenTofu’s drop-in compatibility with Terraform syntax up to version 1.5 means a migration is close to a find-and-replace on the binary and provider blocks, typically completed in one to three days according to migration benchmarks, with no HCL rewrite required.
- Platform engineering team building internal developer platforms. A team building a self-service internal platform on top of Kubernetes and cloud APIs needs real programming constructs (loops, conditionals, shared abstractions, unit tests) more than they need HCL’s declarative simplicity. Pulumi’s use of TypeScript or Go lets these teams write ComponentResources that behave like reusable software libraries, not copy-pasted HCL modules.
- Startup with a small, simple cloud footprint. A five-person startup running one AWS account with a VPC, an RDS instance, and an ECS service doesn’t need Pulumi’s programming-language power or OpenTofu’s state encryption. Either Terraform or OpenTofu keeps the learning curve low, and the choice between them comes down to license preference alone.
- Security-sensitive team with compliance requirements around encryption at rest. A healthcare or fintech team that needs state files encrypted at rest without bolting on a third-party tool benefits from OpenTofu’s native state encryption, a feature HashiCorp hasn’t shipped in Terraform as of this comparison.
CI/CD pipelines: what changes when you switch tools
The IaC tool itself is only one piece of the deployment pipeline. Whatever you pick has to plug into a CI system, gate on policy checks, and produce a plan output that a human can actually review before it applies. This is where the three tools diverge in ways that don’t show up in a feature comparison table.
Terraform and OpenTofu pipelines typically run the same shape of job: a plan step that posts a diff as a pull request comment, a manual approval gate, then an apply step triggered on merge. Terraform Cloud automates that whole flow out of the box. OpenTofu teams either wire it up themselves with GitHub Actions or GitLab CI, or pay a third-party platform like Spacelift or Scalr to manage it. Because the CLI commands and output format are close to identical between Terraform and OpenTofu, existing pipeline YAML usually needs only a binary name change, not a redesign.
Pulumi pipelines look more like a standard software CI job, because from the CI system’s point of view, a Pulumi program is just a TypeScript or Python program that happens to talk to cloud APIs. That means Pulumi projects can run the same linting, unit testing, and static analysis tooling a team already uses for application code, instead of a separate HCL-specific toolchain. Teams that already run strict CI gates on their application repos (required test coverage, type checking, dependency scanning) tend to find it easier to apply those same gates to Pulumi infrastructure code than to a Terraform or OpenTofu module, simply because the tooling already exists for the host language.
Policy enforcement is the other CI-adjacent difference worth planning around. Terraform’s Sentinel policy engine is gated behind paid Terraform Cloud tiers, OpenTofu leans on Open Policy Agent or community tooling that has to be wired in manually, and Pulumi’s CrossGuard policy packs run as part of the same `pulumi up` command without a separate policy engine to stand up. None of the three is objectively better here. It comes down to whether your team already has OPA expertise, already pays for Terraform Cloud’s higher tiers, or would rather write policy checks in the same language as the infrastructure code itself.
Hiring and team skill requirements
Tool choice doesn’t just affect what runs in CI. It affects who you can hire, how fast a new engineer becomes productive, and how much onboarding documentation your team has to write itself versus borrow from the community.
Terraform’s decade-long head start means it still has the deepest bench of practitioners. Job postings that mention infrastructure as code overwhelmingly list Terraform experience as a requirement or a strong preference, and the volume of tutorials, Stack Overflow answers, and third-party courses built around it is not something OpenTofu or Pulumi have caught up to yet, even with OpenTofu’s syntax compatibility carrying over most of that documentation by inheritance. A hiring manager filling an infrastructure role in 2026 will still find Terraform experience the easiest to screen for and the most common on resumes.
OpenTofu benefits from that same talent pool almost by default, since the syntax and mental model transfer directly from Terraform. A team hiring a Terraform-experienced engineer and asking them to work in OpenTofu instead needs essentially zero ramp-up time beyond learning which CLI binary to type. That’s a quieter advantage than the performance benchmarks, but it’s a real one for teams worried that moving off Terraform means shrinking their hiring pool.
Pulumi’s hiring story is different in kind, not just degree. Instead of hiring for “IaC experience,” teams effectively hire software engineers who happen to be applying their existing Python, TypeScript, or Go skills to infrastructure. For organizations that already have strong platform engineering teams staffed with generalist software engineers, this can widen the hiring pool rather than shrink it, since a candidate doesn’t need prior Pulumi-specific experience to be productive quickly. For organizations that specifically want a narrower, ops-focused hire who won’t touch application code, it’s a harder sell, since the pool of engineers who list “Pulumi” as a named skill on a resume is still small relative to Terraform.
Migration guide: moving from Terraform to OpenTofu or Pulumi
Migrating off Terraform isn’t a single procedure, because OpenTofu and Pulumi require fundamentally different amounts of rework. Here’s what each path actually involves.
Terraform to OpenTofu (low effort)
- Audit your Terraform version. OpenTofu supports Terraform syntax up to version 1.5 as a drop-in replacement. State files and modules created on newer Terraform versions may need a compatibility check first.
- Install the OpenTofu binary alongside, not replacing, your existing Terraform binary, so you can roll back if something breaks mid-migration.
- Point your CI pipeline at the tofu binary instead of terraform for a single test environment first, not production.
- Run tofu plan against your existing state file and diff the output against a terraform plan run on the same state to confirm zero unexpected changes.
- Migrate your remote state backend configuration. OpenTofu reads standard Terraform backend blocks (S3, GCS, Azure Blob) without changes.
- Update any CI/CD scripts, Makefiles, or wrapper tooling that reference the terraform binary name explicitly.
- Roll out to remaining environments once the test environment has run clean for at least one full deploy cycle.
- Decommission Terraform Cloud workspaces, if used, once OpenTofu-based CI is confirmed stable, to stop the BSL-tied billing.
Based on published migration case studies, this path typically takes one to three days of engineering time for a mid-size codebase, with a monthly cost delta that’s often negative (a savings) once Terraform Cloud licensing is dropped in favor of self-hosted state or a third-party OpenTofu runner.
Terraform or OpenTofu to Pulumi (high effort)
- Pick a host language for your team. TypeScript and Python are the most common starting points, while Go suits teams prioritizing compiled-binary performance.
- Use Pulumi’s conversion tooling to auto-convert existing HCL modules into a first draft of Pulumi code. Expect to hand-edit the output, not ship it directly.
- Rebuild your state management approach: import existing cloud resources into Pulumi’s state using pulumi import rather than trying to migrate the Terraform state file directly.
- Rewrite reusable Terraform modules as Pulumi ComponentResources, which is where most of the real engineering time goes since it’s a genuine redesign, not a syntax swap.
- Add unit tests using your host language’s native test framework (pytest, Jest, Go’s testing package). This is the step most teams skip and later regret, since testable infrastructure code is Pulumi’s core advantage over HCL.
- Run both toolchains in parallel against a staging environment for at least one full sprint before cutting production over.
- Migrate CI/CD to Pulumi Cloud or a self-hosted backend, and update policy-as-code rules from Sentinel/OPA syntax to CrossGuard.
- Cut production traffic over environment by environment, starting with the lowest-risk service.
This migration typically runs weeks, not days, for any team with a non-trivial existing Terraform footprint. It’s the right call when the destination (testable, reusable, language-native infrastructure code) justifies the cost, not as a default move.
Pros and cons of each platform
Terraform
Pros: largest provider ecosystem at 4,800+, largest talent pool and easiest hiring, deepest third-party tooling and documentation built up over a decade, official enterprise support now backed by IBM.
Cons: BSL 1.1 license carries ongoing vendor-lock-in risk, no native state encryption, slower plan/apply performance than OpenTofu in recent benchmarks, licensing terms already changed once and could change again under IBM.
OpenTofu
Pros: permanently open-source under Linux Foundation governance, drop-in Terraform compatibility for near-zero-effort migration, fastest plan/apply and lowest memory footprint in benchmark testing, native state encryption HashiCorp hasn’t shipped.
Cons: no first-party managed SaaS, so teams pay a third-party runner or self-host state, a smaller community and fewer tutorials than Terraform given its shorter track record, and it still inherits HCL’s DSL constraints rather than a general-purpose language.
Pulumi
Pros: real programming languages with loops, conditionals, and native unit testing, the strongest fit for AI-assisted code generation given larger LLM training data in Python and TypeScript versus HCL, an Apache 2.0 license with no BSL-style risk, and a free unlimited tier for individual use.
Cons: the smallest provider ecosystem at roughly 150 native and bridged providers, the slowest plan/apply times in benchmarks due to language runtime overhead, the smallest talent pool (making hiring experienced practitioners harder), and a migration from existing Terraform or OpenTofu code that requires a genuine rewrite, not a syntax swap.
Verdict: which one should you actually pick
There’s no single winner here, and any comparison that claims otherwise is oversimplifying a decision that depends on where your team already stands. Based on the licensing terms, benchmark data, and pricing above, three clear recommendations emerge.
If your team has an existing Terraform codebase and no strategic reason to stay tied to HashiCorp or IBM, OpenTofu is the default move in 2026. The migration cost is measured in days, not weeks, it’s faster in every published benchmark, and it removes the licensing risk permanently under Linux Foundation governance. This is the highest-value, lowest-risk change most infrastructure teams can make this year.
If your team is already deep in an IBM enterprise relationship, or you depend heavily on Terraform Cloud’s Sentinel policy engine and don’t want to rebuild that governance layer, staying on Terraform remains defensible. The BSL doesn’t affect normal usage rights, and IBM’s backing means the product isn’t going away.
If you’re starting a new platform engineering initiative from scratch, especially one building reusable internal developer platform components, Pulumi is worth the steeper migration cost. Real programming languages, native unit tests, and a stronger fit for AI-assisted development are advantages that compound as your infrastructure codebase grows, even though the provider ecosystem and hiring pool are smaller today.
What shouldn’t happen is picking a tool by inertia. The IaC market changed meaningfully in the past two years, and the 2023 default of just using Terraform no longer holds up against the license, performance, and pricing data available in 2026.
One more factor worth weighing before locking in a decision: reversibility. Moving from Terraform to OpenTofu is close to reversible, since the syntax and state format stay compatible in both directions, so a team that tries OpenTofu and regrets it can switch back with the same one-to-three-day effort it took to migrate in the first place. Moving to Pulumi is not symmetric in that way. The rewrite into a general-purpose language is real engineering work, and unwinding it back to HCL later costs roughly the same weeks of effort as the original migration. That asymmetry doesn’t make Pulumi the wrong choice, but it’s a reason to pilot it on a single non-critical service before committing an entire infrastructure codebase to the switch.
How this compares to container and cloud provisioning choices
IaC tool choice doesn’t happen in a vacuum. Teams running Kubernetes clusters across EKS, AKS, or GKE already make a similar build-vs-buy tradeoff on managed control planes, and the same license-risk logic that pushes teams toward OpenTofu also shows up in how they evaluate managed Kubernetes offerings, a dynamic the Cloud Native Computing Foundation has tracked as open governance becomes a bigger factor in infrastructure tooling decisions industry-wide: teams increasingly weigh vendor lock-in against operational simplicity. A team standardizing on OpenTofu for its provisioning layer commonly pairs it with a Kubernetes distribution chosen for the same reasons, open governance and predictable pricing, rather than defaulting to whichever cloud they happen to already use.
Cost visibility is the other half of this equation. Teams that migrate their provisioning layer to cut licensing risk often make that move alongside a broader FinOps push, since both problems come from the same root cause: infrastructure spend and infrastructure risk becoming visible only after they’re already large. A tool migration that isn’t paired with better cost tracking tends to just move the risk instead of reducing it.
Container security and state file exposure
One risk that gets less attention in the Terraform vs Pulumi vs OpenTofu debate is what happens to state files once they exist. Terraform and OpenTofu state files, and Pulumi’s equivalent checkpoint files, routinely contain plaintext secrets: database passwords, API keys, and connection strings written into a resource’s attributes during a plan or apply. A misconfigured S3 bucket or an over-permissioned CI runner that can read that state file is a direct path to full cloud account compromise, independent of which tool wrote it.
This is where OpenTofu’s native state encryption is a genuine security upgrade rather than just a licensing footnote: it encrypts the state file at rest by default, without requiring a separate KMS integration bolted on after the fact. Terraform and Pulumi users can achieve equivalent protection, but it requires deliberate setup (customer-managed KMS keys, encrypted S3 buckets with strict IAM policies, or a secrets manager reference pattern instead of storing raw values), and teams frequently skip that step under deadline pressure. Whichever tool a team picks, treating the state backend with the same access controls as a production database, not as a build artifact, is the baseline that actually prevents a breach.
Frequently asked questions
Is OpenTofu actually a drop-in replacement for Terraform?
For most configurations written against Terraform 1.5 or earlier syntax, yes. OpenTofu was forked from the last MPL-licensed Terraform release and maintained deliberate syntax compatibility (the project’s full changelog and compatibility notes are published on its GitHub repository), so existing HCL modules and providers generally work without rewriting. Configs using Terraform features shipped after the BSL license change may need adjustment, since OpenTofu’s maintainers build those features independently rather than porting HashiCorp’s proprietary code.
Does the Terraform BSL license affect normal, non-commercial use?
No. The BSL 1.1 restricts building and selling a competing commercial product on top of Terraform’s source code. It does not restrict using Terraform internally to manage your own infrastructure, even at a for-profit company. The practical risk it introduces is about future license changes and vendor dependency, not about today’s usage rights.
Can I mix Terraform, OpenTofu, and Pulumi in the same organization?
Technically yes, since all three manage cloud resources through the same underlying provider APIs and generally don’t conflict if scoped to separate resource groups or accounts. In practice, running more than one IaC tool multiplies the tooling, training, and CI maintenance burden, so most teams standardize on one primary tool and treat a second as a deliberate exception rather than a long-term strategy.
Which tool has the best support for AWS, Azure, and GCP simultaneously?
Terraform and OpenTofu, since both draw from the same 4,800+ provider registry that covers every major cloud in depth. Pulumi supports all three major clouds natively as well, with roughly 150 native and bridged providers total, which is sufficient for the vast majority of multi-cloud setups but thinner on niche or long-tail services within each cloud.
Is Pulumi harder to learn than Terraform?
It depends entirely on what your team already knows. An engineer fluent in Python or TypeScript will likely find Pulumi faster to pick up than HCL, since they’re applying an existing skill rather than learning a new domain-specific language. A team with no strong general-purpose programming background, or one used to reading Terraform modules written by others, will find the HCL-based tools more approachable initially.
Does OpenTofu have official enterprise support?
Not from a single vendor the way Terraform has HashiCorp and IBM, or Pulumi has Pulumi Corporation. OpenTofu support comes through Linux Foundation member companies and third-party platforms like Spacelift, Scalr, and env0, which offer commercial support contracts around OpenTofu without controlling the underlying open source project.
What does it cost to migrate a mid-size Terraform codebase to OpenTofu?
Published migration benchmarks put the engineering time at roughly one to three days for a typical mid-size codebase, given OpenTofu’s syntax compatibility. The bigger ongoing cost variable is which state backend and runner you choose afterward. Self-hosted state is close to free, while a managed third-party runner adds a recurring per-seat cost comparable to or slightly below Terraform Cloud.
Will HashiCorp or IBM ever move Terraform back to an open source license?
There’s no indication of that happening. IBM’s completed acquisition of HashiCorp folds Terraform into IBM’s broader enterprise software strategy, and the BSL model serves that strategy by protecting Terraform Cloud’s commercial position. Teams planning around licensing stability should treat the current BSL terms as the baseline going forward rather than expecting a reversal.
