Which Terraform Enterprise alternative fits your team
Terraform Enterprise fits teams that want a vendor-supported, self-managed product and depend on its existing policy and feature set. Terrakube with OpenTofu fits teams that want an Apache 2.0 platform they run themselves, inside their own Docker, Kubernetes or OpenShift environment. The decision usually turns on four questions. First, how much support you need in writing, and whether a vendor support contract covers the outages and upgrade windows your change process requires. Second, how much of your policy depends on Sentinel. Sentinel policies do not run unchanged on Terrakube, so you need an inventory of every policy set and a plan to rewrite the ones that matter in Rego. Third, where data must physically live, and whether your operator, state files and run logs can stay in the environment you control. Fourth, whether your platform team has the capacity to operate a run platform, including its database, upgrades, backups and access model.
Terraform Enterprise pricing is a custom quote, so this page gives no figures for it. Ask your HashiCorp or IBM account team for a written quote that lists the license tier, the number of managed resources or users it counts, support terms and any renewal uplift. Compare that with the cost of the components you would run yourself: the Terrakube deployment, its database, state storage, the OpenTofu version you pin, and the people who own them. Those costs recur, and they grow with your environment and the staff time you assign to them. Ask each vendor what changes at renewal, and write those answers into the decision record before you choose.
Which scenarios favor Terraform Enterprise and which favor Terrakube
This table compares common situations in which a team running Terraform Enterprise might weigh staying put against moving to Terrakube. Read each row as a condition check: if the condition describes your environment, the named option is the likelier fit, and the notes say what to confirm before deciding.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Large Sentinel policy estate | Terraform Enterprise | Your rules are written in Sentinel and tightly integrated with runs; moving means translating them to Rego and re-testing each policy set. |
| Requirement for a vendor support agreement | Terraform Enterprise | Your procurement or assurance process requires a contracted vendor for the platform. Confirm the support terms directly with HashiCorp, since they are not covered here. |
| Need to run OpenTofu | Terrakube | You want the CLI itself to be OpenTofu under MPL-2.0, which Terrakube supports alongside Terraform. |
| Strict data residency or air-gapped networks | Terrakube | You need the run, state and registry stack inside a network or region you control. Confirm the Terrakube install path and dependencies for an offline environment. |
| Small platform team with limited capacity to operate software | Terraform Enterprise | Your team cannot take on upgrades, database operations and access administration for another platform. Compare the operating effort explicitly before deciding. |
| Existing investment in Kubernetes or OpenShift | Terrakube | Your team already runs workloads on the cluster and can deploy the Helm chart and a supported relational database. Confirm OpenShift-specific steps in the Terrakube documentation. |
| Dependence on Dex-based SSO and group-scoped permissions | Terrakube | Your identity provider is one Dex supports, and your access model maps to groups for workspaces, modules and VCS connections. Verify group mapping before migrating. |
Where your Terraform state and run data live in each option
Both options can run inside infrastructure you control, but you decide where that infrastructure sits and how it is wired. The four cards cover where state and run data are stored, which hosting models are documented, how people authenticate, and what evidence an assessment is likely to ask for.
Where state and run data sit
With Terrakube, state and run data are stored in the database and storage you provision for it. Terrakube supports any relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle and SQL Server, so the database engine and its location are decisions your team owns. Confirm which storage holds state, logs and plan output in the release you choose, along with backup, encryption and region settings. Map where Terraform Enterprise keeps the same data so the comparison covers both sides.
Hosting models you can run
Terrakube documents installation with a Helm chart or Docker Compose, and testing with minikube, so teams on Kubernetes or a single Docker host have a documented starting point. Your Terraform Enterprise installation may already run on Docker, Kubernetes or OpenShift, so compare that footprint directly. OpenShift support for Terrakube must be confirmed for the specific release you plan to deploy, including route, security context and storage requirements. Validate the chosen path in a non-production cluster before committing to it.
Identity and access control
Terrakube authenticates through Dex, which connects to identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. Permissions on workspaces, modules and VCS connections are assigned by group, so group membership in your identity provider becomes the access model. Map every existing team and workspace role to a group before cutover, then test that removing someone from a group also removes their run and state access. Record this mapping alongside your current Terraform Enterprise team settings.
Compliance evidence to collect
DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make that determination. For state, OpenTofu's client-side encryption of state and plan files supports key providers such as AWS KMS, GCP KMS and OpenBao, so record which provider and key policy you use. Collect access reviews, group membership exports, run logs and backup restore tests, and confirm with your auditor which of these they need.
What drives the cost of Terraform Enterprise and self-hosted Terrakube
Terraform Enterprise is sold as a self-managed edition under custom pricing, so its license cost comes from a written quote rather than a published rate. HashiCorp's pricing page lists Terraform Enterprise at custom pricing, while the hosted HCP Terraform tiers bill per managed resource. The license is the largest recurring line for most buyers, and it is usually renewed annually. Beyond the license, you pay for the infrastructure Terraform Enterprise runs on, which is typically Docker, Kubernetes or OpenShift hosts, a PostgreSQL database and object storage for state and logs. Your staff also carry upgrades, backups, certificate rotation and incident response for the installation, and support is included in the subscription but its scope depends on the contract.
- License quote: a recurring custom fee tied to your deployment and terms, renewed on the contract's cycle.
- Infrastructure: compute, storage and load balancing for the appliance, which grows with the number of workspaces and runs.
- Upgrades and operations: staff time for scheduled upgrades, backups and restore tests, which recurs with each release.
- Support: included in the subscription, but confirm the severity levels, response targets and whether upgrade assistance is covered.
- Staff: the platform engineers who operate the installation, a cost that recurs and rises with the number of environments.
Ask the vendor for a written quote that separates the license, support and any add-ons, and confirm which upgrades and deployment assistance fall inside the subscription.
Terrakube is licensed under Apache 2.0, so the software itself carries no license fee. Your costs come from the hosts it runs on, the database behind it, the storage you use for state, and the people who install and operate the platform. Terrakube installs with a Helm chart or Docker Compose, so the compute footprint depends on the hosting model you choose. One-time costs cover the initial setup, identity configuration through Dex, VCS connections and migration of workspaces and state. Recurring costs cover hosts, database backups, storage growth, Terrakube and OpenTofu version upgrades, and on-call coverage for runner failures.
- Hosts: Kubernetes nodes or Docker hosts sized for your concurrent runs, which scale with team size and pipeline volume.
- Relational database: PostgreSQL, MySQL, Oracle or SQL Server, as supported by Liquibase, with licensing that depends on the engine you pick.
- State storage and extensions: object storage for state and plan files, plus tooling such as OPA policy checks or Infracost estimates that you run and maintain.
- Setup and operation: a one-time build and migration effort, followed by recurring upgrades and monitoring by your platform team.
- Optional DeployOpen work: fixed-scope implementation or a retainer for support and upgrades, priced from a written scope if you choose it.
Request a cost model from your team that lists each host, database, storage and staffing line, and confirm the Terrakube and OpenTofu versions you plan to run.
Several factors move both sides of the comparison, and they should shape the quote you request. The number of workspaces, concurrent runs and teams drives compute and database load in either platform. The number of environments you must keep separate, and whether you run high availability, changes the infrastructure line. Regulatory needs such as data residency or air-gapped operation can raise hosting and staffing costs on either side. Staffing is often the largest cost in a self-hosted model, and it is also the item most people underestimate when they compare a license against servers.
- Scale: more workspaces and concurrent runs increase hosts, database capacity and storage on both platforms.
- Availability: high availability and backup testing add infrastructure and operational time.
- Upgrades: how often you apply Terraform Enterprise releases or Terrakube and OpenTofu versions sets the recurring effort.
- Identity and integrations: SSO through Dex or the vendor's SSO, VCS connections and policy tooling each add setup and support work.
- Support model: a vendor contract, an internal team, or a fixed-scope partner each shifts risk and cost differently.
In each quote, ask for one-time and recurring totals separately, the assumptions behind any staffing estimate, and what happens to pricing if your workspace count grows.
Why the license matters for a Terraform Enterprise replacement
The license history explains why this replacement exists at all. On August 10, 2023, HashiCorp announced that all future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1, with the main restriction aimed at vendors offering competitive services. IBM completed its acquisition of HashiCorp on February 27, 2025. In response, a group including Gruntwork, Spacelift and Harness created *OpenTofu*, an MPL-2.0 fork of Terraform under the Linux Foundation, which was accepted to the CNCF Sandbox on April 23, 2025. For a Terraform Enterprise team, the practical question is which license governs the CLI your runs execute. Check which Terraform version your workspaces pin, and record whether your organization's legal review treats the BSL as acceptable for internal use.
Licenses describe rights, but they do not describe support. Terrakube is licensed under Apache 2.0, and Atlantis is also Apache 2.0, while OpenTofu is MPL-2.0. These are facts about each license, and they do not tell you who will fix a defect in your environment. Terrakube support comes from its open-source community and from whichever firm you contract for implementation or maintenance. Ask any partner, DeployOpen included, to put in writing what support paths exist, response expectations, which versions are covered, and whether patches for your Terrakube release are included in the scope. Terraform Enterprise support obligations do not transfer automatically, so plan for this gap explicitly.
Compatibility is the other licensing-adjacent risk. OpenTofu states an aim of maintaining feature parity with Terraform for future releases while its community decides which features it adopts, so compatibility with future Terraform releases is not guaranteed. Before you commit, pin your current Terraform version in the required_version setting, run your configurations against OpenTofu in a non-production workspace, and list any features your teams depend on from newer Terraform releases. Re-test that list each time either tool ships a release, and decide in advance who approves a version change.
What moving off Terraform Enterprise to Terrakube involves
The sequence moves each workspace's state, configuration and access model from self-managed Terraform Enterprise to Terrakube in a controlled order, so that Terraform Enterprise can be retired only after every workspace has been checked.
Inventory organizations, workspaces and policies
Platform or DevOps owners list every organization, workspace, variable set, team, VCS connection, module and policy set in the Terraform Enterprise instance, and note which workspaces depend on others. This list is the migration scope and sets the number of cycles the remaining steps need, so the count of workspaces drives the effort. The step is done when each workspace has an owner, a state location and a named verifier, and the list has been reviewed by the teams that use those workspaces.
Export current state through the state versions API
For each workspace, the engineer who owns it downloads the latest state through the state versions API in Terraform Enterprise, using the JSON download URL for states created by Terraform 1.3 or later and the raw download for older states. Teams store the files in a restricted location with access logging, because state can contain secrets. The step is done when each downloaded file's serial and resource count match what the Terraform Enterprise UI shows for that workspace.
Stand up Terrakube in your cluster
The platform team installs Terrakube with its Helm chart or Docker Compose in the Kubernetes, OpenShift or Docker environment the organization already operates, connecting it to a PostgreSQL or other Liquibase-supported database and configuring Dex with the existing identity provider. Confirm backup, TLS and network paths for the database and the API hostname with your own infrastructure team, since these settings are environment-specific. The step is done when a test workspace can run a plan and apply against a sample configuration.
Recreate organizations, workspaces and group permissions
Platform engineers recreate the organizations and workspaces in Terrakube, then rebuild variables, VCS connections and modules, and map each Terraform Enterprise team to a Terrakube group so that permissions on workspaces, modules and VCS connections follow the same access model. Some objects, such as certain policy sets and team tokens, have no direct export and must be re-created by hand, so confirm each one against the inventory. The step is done when every workspace's permissions have been checked against the inventory by the owning team.
Point configurations at Terrakube and log in
Each team updates its cloud block or remote backend to the Terrakube API hostname, runs terraform login against that hostname, and imports the migrated state into the new backend using the migration path described in the Terrakube CLI-driven workflow documentation. Teams running Terraform older than v1.1 use the remote backend, which also supports state migration. The step is done when a plan against the new backend shows no changes for the existing infrastructure.
Decide when to move to OpenTofu
Leadership and the platform team decide whether the CLI switches to OpenTofu in the same change or in a later one. Keeping Terraform for the first cutover limits the number of variables under test, while moving at once avoids a second migration window. If OpenTofu is chosen, follow the OpenTofu migration steps: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. The step is done when the chosen CLI version is recorded per workspace.
Review terraform_remote_state dependencies
Platform engineers search every configuration for terraform_remote_state data sources, since OpenTofu's migration guidance says these need additional care when moving. Each consumer must point to the new backend location of the producing workspace, and the producer and consumer should be migrated in an agreed order. The step is done when every dependency has been traced, updated and confirmed with a plan that reads the expected outputs.
Retire Terraform Enterprise after verification
Teams verify each workspace with a plan that shows no unexpected changes, a successful apply of a small test change, and a check of the state history in Terrakube. Only when every workspace in the inventory has passed, the organization archives the Terraform Enterprise state and disables the instance on a date agreed with stakeholders. The migration process is designed to be reversible, so keep the exported state and the Terraform Enterprise instance available until the verification is signed off.
Questions buyers ask before choosing a Terraform Enterprise alternative
What drives the cost of running Terrakube compared with a Terraform Enterprise quote?
The main difference is that Terraform Enterprise is quoted on custom terms, while Terrakube is free software whose cost sits in infrastructure, storage, setup and the people who run it. Terraform Enterprise quotes depend on the contract, the deployment size and the support level, so ask the vendor for the full written terms. On the Terrakube side, the recurring costs are the compute and database the platform runs on (Terrakube supports PostgreSQL, MySQL, Oracle and SQL Server through Liquibase), state storage, backups, upgrades and the engineer time to operate it. Ask for each of these as separate line items so you can compare like with like, including any support retainer you would need.
How long does a Terraform Enterprise to Terrakube migration take?
The duration depends mainly on the number of workspaces, how many depend on each other, and how much of the configuration is connected to VCS, variables and teams. A small set of independent workspaces moves quickly, while a estate with shared outputs and cross-workspace references needs more planning and more verification after each cutover. Terraform Enterprise state is exported through the state versions API, and you should recreate organizations, workspaces, variables and VCS connections on the Terrakube side before switching the cloud block or remote backend. No duration is stated here because it should come from a written plan based on your inventory. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
What does the migration need from our own engineering team?
Your team needs to supply the knowledge of the estate and make decisions that only the owners can make. That includes an inventory of workspaces, their state locations, variables and secrets, VCS links and team memberships, plus the owners who can approve cutover windows. Engineers also need access to the Terraform Enterprise API and the Terrakube environment, and someone must own the identity setup through Dex with your identity provider. Expect reviews of each plan output before and after cutover, and agreement on whether the move goes to OpenTofu at the same time or later. Ask the implementation partner to list these inputs in the written scope so the dependency on your staff is visible before work starts.
Can our team complete the migration to Terrakube without outside help?
A team with strong Terraform and platform experience can do the migration alone, provided it has time to run the work alongside its normal duties. The risks are in the details: cross-workspace data sharing through the terraform_remote_state data source needs extra care, state must be verified after each move, and the platform must be hardened and backed up before it carries production runs. Terrakube documents installation with a Helm chart or Docker Compose, so the deployment itself is well-trodden. Weigh your team's capacity against the number of workspaces and the audit evidence you must keep. If you bring in a partner, DeployOpen plans, implements, hardens, backs up and documents the platform in your own infrastructure under a written scope.
Do our Sentinel policies carry over to Terrakube?
Sentinel policies do not run on Terrakube, so they must be rewritten rather than copied. Their logic usually translates to Rego, the policy language used by Open Policy Agent, and Terrakube's OPA extension runs those checks inside runs. Plan the translation as its own work item, because each policy needs its inputs, its enforcement level and its test cases confirmed against the new plan data. Keep in mind that the OPA extension is covered on a separate page that explains the translation and how Atlantis policy checks differ. Ask for the list of policies in scope, and confirm with your policy owners which ones must stay blocking before cutover.
Is OpenTofu required to run Terrakube?
No. Terrakube runs both Terraform and OpenTofu, so you can keep the BSL-licensed Terraform CLI during the move and switch later. Choosing OpenTofu is a separate decision driven by licensing, feature direction and state encryption needs. OpenTofu is licensed under the Mozilla Public License 2.0 and is a drop-in replacement for Terraform that preserves existing workflows, though the project does not guarantee compatibility with future Terraform releases. OpenTofu also adds client-side state and plan encryption with providers such as AWS KMS, GCP KMS and OpenBao. Decide whether to switch at the same time as the platform move, and confirm that each provider and module you depend on works with your chosen version.
How DeployOpen helps evaluate a Terraform Enterprise alternative
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Terraform Enterprise vs Terrakube, we help you test the fit against your own workspaces, identity setup and policy needs before any cutover decision is made.
How we scope
- Inventory your Terraform Enterprise organizations, workspaces, variables, teams and VCS connections before anything is compared
- Agree the written scope for Terrakube deployment, identity through Dex, policy extensions and OpenTofu adoption before work starts
- Confirm which Terraform Enterprise features your scope needs, such as private registry, run tasks or Sentinel policies, and which will be replaced
How we build
- Deploy Terrakube on your Docker, Kubernetes or OpenShift environment using the Helm chart or Docker Compose options, configured to your standards
- Connect the database your organization uses, from PostgreSQL to other databases that Liquibase supports, and wire in your VCS providers
- Test a pilot workspace end to end with the cloud block or remote backend, including state migration and a small change to verify the run
How we hand over
- Deliver configuration, runbooks and architecture documentation covering workspaces, groups, registry modules and extension setup
- Provide a documented rollback path for each workspace, so state can be restored and runs returned to the previous platform if needed
- Train your platform team on operating Terrakube, managing permissions by group and running OpenTofu alongside or instead of Terraform
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing after the initial engagement
- Plan Terrakube version upgrades against the release notes, testing each one in a non-production environment first
- Ask any provider for a written quote that separates infrastructure, storage, setup and the internal team's time from licensing
