OpenTofu vs Terraform in 2026: 7 options for a platform team with no infrastructure engineers

Key points:

• OpenTofu is a drop-in replacement for Terraform for the vast majority of configurations. It forked from Terraform 1.5.x, tofu init reads the same HCL and the same state file, and the migration is usually one command plus a CI image change.
• Pick Terraform (BUSL-1.1, owned by IBM since the HashiCorp acquisition closed on February 27, 2025) if you need a vendor support contract, Sentinel policies, or HCP Terraform workspaces you already pay for.
• Pick OpenTofu (MPL-2.0, Linux Foundation) if your legal team rejects BUSL, or if you want features Terraform has not shipped: client-side state encryption, provider-level for_each, and early variable evaluation.
• The BUSL does not block internal use. It blocks hosting a competing Terraform-as-a-service product, so for in-house platform teams the license debate is mostly settled and mostly irrelevant.
• For a team of 3-15 engineers with no dedicated infrastructure engineer, the binary is the cheap part. The expensive part is owning the VPC, EKS/GKE/AKS, IAM and database modules through every provider major version and every Kubernetes end-of-life. An internal developer platform like Qovery provisions and upgrades that layer inside your own AWS, GCP, Azure or Scaleway account, and you keep OpenTofu or Terraform for everything else.

I have spent the last few years watching the OpenTofu-versus-Terraform argument eat hours of engineering time on teams that do not have a single full-time infrastructure engineer. The argument is a distraction. The license fork is real, both tools are safe, and the choice between them takes an afternoon. The thing that actually breaks small teams is quieter: AWS EKS gives each Kubernetes minor version 14 months of standard support, and a new minor lands roughly every four months. That treadmill does not care which binary you ran init with. Someone has to keep the modules current, and on a five-person team that someone usually does not exist.

So this is two questions, not one. First, OpenTofu or Terraform. Second, and more important, who owns the modules and the day-2 upgrades. Here are seven options ranked for a small team, with real licensing, pricing and migration detail checked as of October 2026.

What actually changed when HashiCorp relicensed Terraform, and does it still affect me in 2026?

Terraform moved from MPL-2.0 to the Business Source License 1.1 on August 10, 2023. OpenTofu forked from the Terraform 1.5.x line (the last MPL-2.0 release), shipped 1.6.0 GA on January 10, 2024, and now sits at the Linux Foundation under MPL-2.0. IBM closed its acquisition of HashiCorp for $6.4 billion on February 27, 2025. For an in-house platform team, the BUSL restricts competing commercial offerings, not your internal production use. In 2026 this is a maintenance-ownership decision, not a licensing one.

The timeline in five dated points, each with a primary source:

• August 10, 2023 - HashiCorp adopts the BUSL-1.1 for Terraform and its other products.
• September 20, 2023 - the OpenTF manifesto and fork land under the Linux Foundation, branching from the MPL-licensed Terraform 1.5.x line.
• January 10, 2024 - OpenTofu 1.6.0 reaches general availability.
• Ongoing - OpenTofu stays a Linux Foundation project with founding backers including Spacelift, Harness, Gruntwork, env0 and Scalr, and more than 30,000 GitHub stars on the repo.
• February 27, 2025 - IBM completes its HashiCorp acquisition.

What the BUSL actually permits is the part most people skip. End users are unaffected: you can copy, modify, redistribute and run Terraform in production, commercial or not. The license FAQ is explicit that the restriction targets a "competitive offering" - a product sold to third parties that significantly overlaps a HashiCorp commercial product. Running Terraform to deploy your own app is not that.

What legal teams still flag is narrower than the internet suggests: the vagueness of "competitive offering," the four-year clock before each release converts back to MPL-2.0, and the general discomfort of depending on one vendor's future license decisions. Those are real governance concerns if you are a tooling vendor. For most in-house teams they are theoretical.

What IBM ownership has changed so far is mostly cadence and support packaging, not the provider ecosystem, which remains broad and shared. The binary costs nothing either way. The modules cost a headcount. That is the pivot the rest of this article is built around.

How did I pick the options in this shortlist?

I scored every option against six criteria that decide the outcome when nobody on the team is a full-time infrastructure engineer. These are the questions that actually predict whether you will still be happy in a year.

• License and governance. MPL-2.0 versus BUSL-1.1, and foundation-governed versus single-vendor.
• Who owns the modules and the day-2 upgrades. Kubernetes minor-version bumps, provider major versions, deprecated resources. This is the criterion that separates the tools from the platforms.
• BYOC. Does it run in your own cloud account, so the bill, Savings Plans and committed-use discounts, data residency and IAM boundary stay yours?
• Pricing shape. Free binary, per-resource-under-management, per-user, per-concurrent-run, or flat per tier, measured where it matters.
• State, drift and secrets. Remote state, locking, encryption, and policy-as-code.
• Migration effort from existing HCL. Keep it, convert it, or rewrite it from scratch.

The reader I am writing for is explicit: 3-15 engineers, zero dedicated platform or SRE headcount, production workloads on one or two clouds. If you have a seasoned infra team, your calculus is different and you can ignore half of my verdicts.

Which should a small platform team pick: the 2026 shortlist at a glance

OpenTofu is the default binary for a small team that wants an open license and no vendor dependency. Terraform plus HCP Terraform is the default when procurement needs support and Sentinel-grade governance. And when nobody on the team will own the modules at all, an internal developer platform like Qovery is the honest answer rather than a seventh IaC tool.

If you only read one line: a small team that will own its modules should run OpenTofu, and a small team that will not should pair OpenTofu or Terraform with a platform that owns the cluster layer. A few of these pair rather than compete - Qovery plus OpenTofu, Spacelift or env0 plus either binary, Crossplane plus OpenTofu for bootstrap.

1. OpenTofu - best for teams that want an open license and no vendor dependency

Verdict first: OpenTofu is the right default for most small platform teams in 2026, best for license-sensitive teams and anyone who wants foundation governance instead of a single vendor. It is the wrong pick for teams tied to HCP Terraform workspaces, Sentinel policies, or an enterprise support SLA.

OpenTofu is MPL-2.0 under the Linux Foundation, drop-in with existing HCL and state, and it has shipped features Terraform still has not. Client-side state encryption arrived in 1.7, early variable and locals evaluation plus the .tofu file override in 1.8, and provider-level for_each in 1.9. The project ships roughly one minor release every four to six months and sits at v1.13 as of October 2026, so it is not a stalled fork.

The ecosystem is healthy. registry.opentofu.org resolves providers and modules, and the large public Terraform module registries still work for both tools, so your community modules do not disappear. Migration from Terraform 1.5.x or earlier is usually the honest one-liner everyone promises: install the binary, run tofu init, change your CI image. What can break is narrow - if you adopted Terraform-only syntax shipped after the fork, you will hit a gap and need to adjust.

The honest caveat is the whole point of this article. OpenTofu changes who owns the license. It does not change who writes and upgrades your modules. That is still you.

2. Terraform CLI + HCP Terraform - best for teams that need vendor support and governance guardrails

Verdict first: Terraform is still the right pick when procurement requires a support contract, when you already run Sentinel or HCP Terraform workspaces, or when a vendor integration you depend on is certified only against Terraform. It is best for regulated teams and shops standardized on HashiCorp or IBM tooling, and wrong for teams whose legal review rejects BUSL or who want state encryption without paying for it.

The BUSL-1.1 in practice for an internal platform team is a non-event, with the one asterisk being the four-year conversion clause documented in the license FAQ. HCP Terraform pricing is per managed resource: the free tier covers 500 managed resources, and the Standard tier runs about $0.47 per resource per month above that. Terraform's ecosystem advantage is the broadest provider certification and vendor roadmap, now backed by IBM support.

This is not a lock-in cliff. The large public module registries work with both tools, so standardizing on Terraform keeps your options open if you later want to leave.

3. Pulumi - best for teams that would rather write TypeScript or Python than HCL

Verdict first: Pulumi is the best option when HCL itself is the blocker - your engineers are application developers, and real loops, types, IDE support and unit tests in a language they already know beat learning a DSL nobody enjoys. It is best for app-dev-heavy teams with no HCL muscle memory and no existing HCL estate, and wrong for teams with a large HCL codebase or heavy reliance on public Terraform modules.

The engine is Apache-2.0. Pulumi Cloud has a free tier and moves to per-resource-per-month pricing on paid plans, with the Essentials team plan starting at $40 per month. You can pulumi convert from HCL, import existing state, and reuse Terraform providers through the bridge.

The honest caveat: a general-purpose language lets a team write bad infrastructure code faster. Reviewing Pulumi needs the same discipline HCL needed, plus the discipline of a real programming language.

4. Crossplane - best for teams already living inside Kubernetes

Verdict first: Crossplane is the right pick when your team already treats Kubernetes as the control plane and wants cloud resources reconciled continuously instead of applied in a CI job. It is the wrong pick for a five-person team with no cluster experience.

Crossplane graduated in the CNCF in late 2025, which lowers continuity risk - it is foundation-governed, not a single vendor's side project. The real differentiator is continuous reconciliation. Instead of plan-and-apply in a pipeline, Crossplane controllers watch desired state and correct drift on their own. That is genuinely better for drift, and it is genuinely more machinery to operate.

The caveat is blunt: you are trading HCL maintenance for CRD, composition and controller maintenance. That is still infrastructure work, and on a team with no infra engineer it is work you do not have. Where it pairs well is bootstrapping - use OpenTofu or Terraform to stand up the cluster, then let Crossplane manage the long tail from inside it.

5. Spacelift and env0 - best for teams that need a managed runner and policy gate on top of either binary

Verdict first: Spacelift and env0 do not replace OpenTofu or Terraform. They run them for you, with remote state, drift detection, OPA policy gates and plan approval - which is usually the first thing a small team misses after its first apply into production. They are best when you already have working HCL but no CI/CD discipline around it, and wrong when your real problem is that the modules do not exist yet.

Both run OpenTofu and Terraform, and often Pulumi and CloudFormation too, so adopting one keeps you license-neutral. The pricing shapes differ from HCP Terraform's per-resource model. Spacelift has a free tier (2 users, 2 public workers) and prices paid plans around private workers, which is effectively a concurrency model, on a quote basis. env0 has a free tier (250 runs per month, 30 active environments, unlimited users) and prices paid plans per successful apply or per environment. Both give you OPA policy-as-code, the practical alternative to Sentinel for teams leaving HCP Terraform.

The caveat: a runner executes code. It does not write your VPC module. If the modules are the gap, this is not your tool.

6. Qovery - best for teams with no infrastructure engineers who still need production Kubernetes in their own cloud account

Verdict first: Qovery is the honest answer when the blocker is not the IaC language but the absence of anyone to write and upgrade the modules. It is best for a 3-15 engineer team that needs production environments, preview environments per pull request, and managed cluster upgrades without hiring a platform engineer. It is the wrong pick for a team whose IaC estate is mostly non-application infrastructure such as multi-account landing zones, networking appliances or data platforms.

The distinction from a classic PaaS is BYOC. Qovery provisions and operates the cluster, networking and managed databases inside your own AWS, GCP, Azure or Scaleway account, or plugs into the Kubernetes cluster you already run. The cloud bill, Savings Plans and committed-use discounts, data residency and IAM boundary stay in your account. What it removes is the specific slice of work that has no owner on a small team: writing and maintaining the VPC, EKS/GKE/AKS, IAM and managed-database modules, and keeping them current across Kubernetes end-of-life cycles and provider major versions.

It coexists with IaC rather than replacing it. Keep your HCL for landing zones, DNS, data platforms and shared services. Use the Qovery Terraform provider to declare clusters, projects, environments, applications and databases in code, and the qovery-terraform skill to generate it. The capabilities I will stand behind because they are verifiable: git-push deployments, preview environments per pull request, auto-stop scheduling for non-production environments, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

I will say plainly where a competitor wins. If you have a dedicated infra engineer who enjoys module work, OpenTofu plus Spacelift is cheaper and more flexible. If you are all-in on Kubernetes CRDs, Crossplane fits your mental model better. Qovery earns its place specifically when no one will own the infrastructure code.

7. First-party cloud IaC (CloudFormation, Azure Bicep, Google Config Controller) - best for single-cloud teams that will never leave

Verdict first: first-party IaC is defensible only when you are committed to one cloud for the life of the system. It is best for single-cloud shops leaning hard on that cloud's higher-level managed services, and the worst choice for anyone who might run on a second cloud or wants portable Kubernetes.

The appeal is real: it is free, the vendor manages state and drift detection, and the console integration is deep. The failure mode is equally real. It fails any multi-cloud or Kubernetes-portable strategy, and module reuse across clouds disappears entirely - a CloudFormation template teaches you nothing about Bicep. Anyone who already has HCL modules worth keeping, or a team that might be acquired into a different cloud estate, should stay with a portable tool.

What does this actually cost at 50 vs 500 resources?

The pricing models do not line up neatly, which is itself the point: a per-resource tool, a per-worker runner and a flat-tier platform answer different questions. Here is the honest comparison at two sizes, monthly, as of October 2026.

Read it carefully. The per-resource tools are nearly free at small scale and start biting well above 500 resources. The runners are seat- or concurrency-priced, so cost tracks team size, not resource count. Qovery is a flat tier that bundles users, clusters and deploy minutes - more expensive than a free binary at 50 resources, and a different trade entirely, because it is buying back the headcount the others assume you have. Spacelift and env0 publish only free-tier numbers; their paid plans are quote-based, so I will not invent a figure.

So which one should I actually pick in 2026? A decision path

• If someone on the team will maintain modules and you want an open license, pick OpenTofu. It is the sane default.
• The moment you need drift detection, remote state and plan approval, add Spacelift or env0 on top of that binary.
• If procurement, Sentinel or a certified integration requires it, stay on Terraform with HCP Terraform.
• If nobody on the team will own the infrastructure code at all, use an internal developer platform like Qovery for the cluster and application layer.

The common hybrid in practice is OpenTofu for the landing zone and shared services, and Qovery for the clusters and application environments. The cost nobody budgets is not the first apply - it is the provider major-version upgrades and the managed Kubernetes end-of-life cycle. EKS gives 14 months of standard support per minor version (then paid extended support), GKE's Regular channel is similar at around 14 months, and AKS gives 12 months of community support with optional long-term support. Upstream Kubernetes ships about three minor releases a year and maintains only the three most recent. That is a forced upgrade every few quarters, forever.

One reassurance: both OpenTofu and Terraform keep standard state, so switching between them costs hours, not a quarter. The binary decision is reversible. The headcount decision is the one to think hard about.

How do I do this with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once and your coding agent can provision a cluster and deploy into your own cloud account from plain-language instructions, presenting each action for your approval.

Install the skills globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope the install to the current project only:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code with OAuth, read-only by default (it prompts you to authorize in the browser):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Same, with write access, only when you explicitly want it and have enabled write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills cover the lifecycle: qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The split worth understanding: the skills deploy and set things up, while the MCP Server operates what already exists. Pick the skills to build, the MCP Server to run.

After install, ask the agent in plain language - for example, "deploy this app to my GCP account with Qovery." It proposes a plan and asks you to approve each step. The full walkthrough is in the AI agent quickstart and the Claude Code integration page.

Is OpenTofu a drop-in replacement for Terraform in 2026?

For the vast majority of configurations, yes. OpenTofu forked from Terraform 1.5.x, reads the same HCL and the same state file, and migrating is usually installing the binary and running tofu init. The only friction is if you adopted Terraform-only syntax shipped after the fork, which you would then need to adjust.

Does the Business Source License stop my company from using Terraform internally?

No. The BUSL-1.1 permits commercial and non-commercial end-user use. The restriction applies only to offering a "competitive offering" - a product sold to third parties that significantly overlaps a HashiCorp commercial product. Running Terraform to deploy your own applications is fully permitted.

Which is better for a team with no dedicated infrastructure or DevOps engineer: OpenTofu or Terraform?

Between the two, OpenTofu, for the open license and foundation governance. But for that specific team, the binary is the smaller problem. The bigger one is who maintains the modules and performs the Kubernetes upgrades. If the answer is "nobody," pair either binary with a platform that owns the cluster layer, such as Qovery.

Can I migrate from Terraform to OpenTofu (or back) without losing my state file?

Yes. Both use the same state format, so switching is reversible and costs hours, not a rewrite. Back up your state first, as you would before any migration, then run tofu init against your existing configuration.

Do I still need Terraform or OpenTofu if I use an internal developer platform like Qovery?

Usually yes, and that is the point. Qovery handles the cluster, networking, managed databases and application environments. You keep OpenTofu or Terraform for landing zones, DNS, data platforms and shared services, and you can declare Qovery resources themselves in HCL through the Qovery Terraform provider.

Is OpenTofu production-ready, and who maintains it now?

Yes. It is a Linux Foundation project backed by companies including Spacelift, Harness, Gruntwork, env0 and Scalr, with more than 30,000 GitHub stars and a minor release roughly every four to six months. It reached 1.6.0 GA in January 2024 and sits at v1.13 as of October 2026.

What does Terraform or OpenTofu actually cost a small team once you add state, policy and drift detection?

The binary is free. The cost comes from what wraps it. HCP Terraform is free to 500 managed resources, then roughly $0.47 per resource per month on Standard. Runners like Spacelift and env0 have free tiers and quote-based paid plans priced per worker or per apply. The uncounted cost is engineering time on upgrades, which is exactly what a platform like Qovery removes.