What Is an OpenTofu Management Platform?

The OpenTofu CLI plans and applies infrastructure well. What it doesn't do is store state safely for a team, stop two people applying at once, decide who can touch production, or tell you when reality has drifted from your code. An OpenTofu management platform is the layer that adds those things around the runs.

What is an OpenTofu management platform?

It is a service that runs your OpenTofu plans and applies remotely and adds the controls a team needs on top: a shared remote backend with state locking, role-based access control, policy-as-code, drift detection, and an audit trail. You keep writing standard OpenTofu, and the platform takes over execution, state, and governance instead of you wiring them together from cloud storage, a CI runner, and a pile of scripts.

The distinction matters because the CLI is single-player by design. It assumes one operator, one working directory, and a backend you configured yourself. The moment a second engineer needs to run a plan against the same state, you need locking. The moment an auditor asks who changed the database tier, you need a log. Those needs are what the platform category exists to serve, and they are the same whether the engine underneath is Terraform or OpenTofu.

Why do teams need a platform for OpenTofu specifically?

Adopting OpenTofu often comes bundled with a second decision. Many teams moved to OpenTofu after HashiCorp changed Terraform's license in August 2023, and a good number of them were also reconsidering where their runs execute at the same time. If you are already changing engines, it's a natural moment to ask whether your remote-operations layer runs the engine you're standardizing on.

That is where a lot of teams hit a wall, because the most obvious managed option doesn't run OpenTofu at all.

Does HCP Terraform support OpenTofu?

No. As of July 2026, HCP Terraform's managed runs execute the Terraform binary only, and there is no setting to run OpenTofu instead. OpenTofu can use HCP Terraform's remote backend purely for state storage, but the managed run engine, Sentinel policies, and no-code modules are all Terraform-only.

So a team that has committed to OpenTofu can keep HCP Terraform as a state store, but not as the thing that runs their plans and applies. For most people that defeats the point of a managed platform. This is the single most common reason teams standardizing on OpenTofu end up shopping for a different control plane.

Which platforms run OpenTofu?

Five come up most often. Three are SaaS control planes, and two are open-source tools you host yourself.

Platform	Runs OpenTofu	Hosting	Pricing model
Scalr	Yes, native (same billing as Terraform)	SaaS, with optional self-hosted agents	Per run, free up to 50 runs/month
Spacelift	Yes (workflow tool set to OpenTofu)	SaaS, with self-hosted workers	By concurrent private workers
env0	Yes, native	SaaS, with self-hosted agents	By tier and active-environment count
Terrakube	Yes (engine chosen per workspace)	Self-hosted (open source, Apache 2.0)	No license fee, you operate it
Atlantis	Yes (tofu distribution)	Self-hosted (open source)	No license fee, you operate it
HCP Terraform	No (Terraform binary only)	SaaS, with self-hosted agents	Not an OpenTofu option

A few notes behind the table. Spacelift exposes a workflow-tool setting whose value can be OpenTofu, and you pick the version per stack. env0 connects OpenTofu repositories the same way it connects Terraform ones, with state, plan-on-PR, drift, and cost all working. Terrakube added OpenTofu selection at the workspace level, and Atlantis runs tofu once you set its distribution to opentofu. Scalr is a founding member of the OpenTofu project and runs OpenTofu as a native engine, billed exactly like a Terraform run.

For the self-hosted comparison specifically, the OpenTofu plus Atlantis versus a managed platform breakdown walks through where running your own stack costs less and where it costs more.

How much does an OpenTofu management platform cost?

The headline numbers are less useful than the model each vendor uses to count your usage, because that is what decides whether the bill tracks your team or fights it.

• Scalr bills per run, and the free tier covers up to 50 runs a month with two concurrent runs. There are no per-user or per-resource charges, so the engine you choose (Terraform or OpenTofu) doesn't change the price. See the pricing page for the current tiers.
• Spacelift prices paid tiers by the number of concurrent private workers, which is the compute that executes your runs. Users are unlimited; worker count is the lever.
• env0 prices by tier and the number of active environments, with unlimited users and runs across tiers.
• Terrakube and Atlantis have no license fee. The cost is the engineering time to run the server, wire up state storage and locking, handle secrets, and keep it patched.

Check the vendors' own pricing pages for exact figures before you commit, since worker counts, environment caps, and tier boundaries change. The point here is to match the counting model to how you work: bursty plan-heavy teams and steady high-concurrency teams get very different bills from the same platform depending on whether it charges per run, per worker, or per environment. Our own take on why per-run beats the alternatives for most teams is in how to evaluate IaC platform pricing models.

How do I choose an OpenTofu management platform?

Start with three questions. First, is running OpenTofu a hard requirement or a nice-to-have? If it's hard, HCP Terraform is out and you're choosing among the platforms above. Second, do you want to operate the control plane yourself? If yes, Terrakube or Atlantis; if no, a SaaS platform. Third, which pricing model fits your run pattern? Map your monthly run count, your concurrency needs, and your environment count against per-run, per-worker, and per-environment pricing, and one of them will usually be clearly cheaper for how your team actually operates.

If you're weighing this as part of a broader move off Terraform Cloud, the guide to selecting a Terraform Cloud alternative covers the migration side, and OpenTofu versus Terraform covers the engine decision itself.

Scalr runs OpenTofu natively on usage-based pricing that's free up to 50 runs a month, with state, locking, RBAC, policy, and drift detection included. If you want to keep OpenTofu without running the backend and workers yourself, it's a straightforward place to start.