HCP Terraform vs Terrakube

HCP Terraform is the lower-effort hosted choice, while self-hosted Terrakube with OpenTofu fits teams that must keep state, runs and identity inside their own infrastructure. The right answer depends on residency rules, staffing and how many workspaces you run.

Book a callTalk to us
On this page

Which option fits your team: HCP Terraform or self-hosted Terrakube

If your renewal, licensing change or residency requirement forces a decision now, HCP Terraform fits teams that accept hosted run and state storage and have no constraint on where that data lives. Terrakube fits teams that must keep state and run data inside infrastructure they control, prefer OpenTofu, and want sign-in through an existing identity provider brought in with Dex. Both support the same organization, workspace and private registry model, so the choice is about where the platform runs and who operates it, not about losing the workflow. HCP Terraform fits when operations are hosted and your platform team is small. You give up nothing on data location because there is none to control, and you avoid patching, backing up and upgrading the run platform yourself. It also fits when you already depend on Sentinel policies or HashiCorp-specific features that you have not yet translated. Confirm with HashiCorp what your current plan includes, because the managed resource count and tier limits drive the bill, and that cost moves with growth. Terrakube fits when state and run logs must stay in your own network, when you want to run OpenTofu under the MPL-2.0 license instead of Terraform under the Business Source License, and when your staff can operate a database-backed service. Its identity model uses Dex with groups that receive permissions on workspaces, modules and VCS connections. The decision turns on five questions: where data may reside, how many people you can assign to run the platform, how many workspaces you run, which VCS providers you use, and whether policy checks must run with OPA. Answer those first, then compare costs.

Which scenarios favor HCP Terraform and which favor Terrakube

The table maps common buyer scenarios to the platform that fits better and states the condition that makes each advantage matter. Read each row against your own constraints, since the same requirement can favor either side depending on whether you have a platform team and where state must live. Most teams will find that one or two rows decide the question.

ScenarioBetter fitReason and condition
State and runs must stay in your own cloud account or data centerTerrakubeHCP Terraform runs on HashiCorp's hosted service, while Terrakube runs in infrastructure you control. This matters when auditors or data residency rules require state, plan output and variables to remain in your environment.
No platform team to operate a database, upgrades and backupsHCP TerraformA hosted service removes the need to run Terrakube's relational database, Dex and API components yourself. This matters when no one on staff can own patching, backups and upgrades for an additional service.
Existing GitLab, Bitbucket or Azure DevOps codeTerrakubeTerrakube connects to GitHub, GitLab (EE and CE), Bitbucket and Azure DevOps to retrieve code. Confirm that your specific VCS edition and webhook setup are covered before you commit.
Sentinel policies already in useHCP TerraformSentinel runs natively in HCP Terraform, so existing policy sets keep working. Moving to Terrakube means translating policies to Rego for its OPA extension, which is effort you should estimate before choosing it.
OpenTofu is required as the IaC engineTerrakubeTerrakube documents running OpenTofu as well as Terraform, and OpenTofu is MPL-2.0 licensed. This matters when a license or governance policy rules out BSL-licensed Terraform. Confirm the OpenTofu version you pin is supported by your chosen Terrakube release.
Single-team use with small resource counts on a free tierHCP TerraformThe enhanced Free tier covers up to 500 managed resources with unlimited users, according to HashiCorp. This matters while your footprint stays inside that limit and you do not need self-hosted controls.
Private modules and providers must live in your own registryTerrakubeTerrakube provides a private registry for Terraform modules and providers. This matters when module sources must not leave your network, though you should confirm how your module source addresses change.
Plan approvals and pull request workflows only, without a hosted run UIAtlantisIf the main need is plan comments and approvals on pull requests, a lighter Atlantis deployment may suffice. Compare this with Terrakube if you also need a workspace UI, registry and team permissions.

How Terrakube maps HCP Terraform's organization, workspace and registry model

Terrakube covers the same core hierarchy that HCP Terraform uses: organizations contain workspaces, and workspaces hold the state, variables and run history for one set of infrastructure. Its documentation describes it as a collaboration platform for remote IaC operations with Terraform or OpenTofu, so a team that already groups workspaces by organization can keep that layout. Permissions on workspaces, modules and VCS connections are assigned by group through Dex, which is closer to group-based team access than to a one-to-one copy of HCP Terraform's team settings. Map each HCP Terraform team to a group in your identity provider before you create workspaces, and check that the group grants match what each team could do before.

Runs start from the CLI in two ways. The remote backend works with Terraform versions earlier than 1.1 and also supports migrating state. The cloud block needs Terraform v1.1 or later and points the configuration at the Terrakube API hostname. In both cases, users authenticate with terraform login against that hostname, so each engineer's CLI session is tied to the identity provider configured for Terrakube. Confirm the exact hostname, organization and workspaces values with the Terrakube CLI-driven workflow documentation before you change any configuration in a shared repository.

The private registry holds Terraform modules and providers inside Terrakube, so module sources in your configurations will change from the HCP Terraform registry path to your Terrakube host. Treat the feature list as a checklist, not an assumption. Confirm in your own version whether run tasks, agents, health checks and team-level roles in HCP Terraform have a direct Terrakube equivalent, and whether any gap is covered by an extension, an external system or a process change. Write down each HCP Terraform feature your teams use today and the owner of its replacement before the first workspace moves.

Capability comparison: HCP Terraform and Terrakube

This table compares HCP Terraform with self-hosted Terrakube across runs, state, VCS, registry, identity, policy and deployment. Rows marked as items to confirm are areas where the supplied documentation does not settle the answer, so test them in a non-production Terrakube instance before you commit to a migration.

CapabilityHCP TerraformTerrakube (self-hosted)
CLI-driven runsRuns start from the Terraform CLI against a hosted workspace with the run UI in HashiCorp's cloudRuns start from the Terraform or OpenTofu CLI and execute on your Terrakube installation
Remote backend and cloud blockSupports the cloud block and remote backend for hosted workspacesSupports both the remote backend and the cloud block; the cloud block needs Terraform v1.1 or later
VCS integrationsConnects to major VCS providers for workspace-triggered runsRetrieves code from GitHub (cloud and Enterprise), GitLab (EE and CE), Bitbucket and Azure DevOps; confirm trigger behavior for your provider
Private registryHosted private registry for Terraform modules and providersBuilt-in private registry for Terraform modules and providers; confirm provider publishing workflow in a test instance
SSO and identityHosted SSO configuration managed by HashiCorpAuthentication through Dex with Azure Active Directory, Amazon Cognito, GitHub or SAML; confirm your identity provider in a test environment
Group-based permissionsTeam-based access to workspaces and settingsPermissions on workspaces, modules and VCS connections assigned by group; confirm that the granularity matches your access model
Policy checksNative policy checks managed within the hosted serviceOPA policy checks available through a Terrakube extension; policy authoring and rule translation are your responsibility
Cost estimatesCost estimation is part of the hosted run workflow; confirm which tiers include itInfracost cost estimates available through a Terrakube extension; you must supply Infracost access
Database supportHosted by HashiCorp; not configurable by the customerAny relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle and SQL Server
Installation optionsHosted service; self-managed edition is Terraform EnterpriseHelm chart or Docker Compose; testing documented with minikube
LicenseProprietary hosted serviceApache 2.0
IaC engineTerraform under the Business Source License 1.1OpenTofu (MPL-2.0) or Terraform; choice is set per workspace and CLI version

Where your state, runs and credentials live under each option

Moving from HCP Terraform to Terrakube changes who hosts state, run logs, variables and credentials, and who patches and backs them up. The cards below list the decisions and checks that follow from that shift, so you can confirm where data sits before you commit to a design.

Where state and plan data sit

HCP Terraform keeps workspace state and run data in HashiCorp's hosted service. With Terrakube, state and run artifacts land wherever you configure storage and the database, inside your cloud account, data center or air-gapped network. Confirm which regions and accounts hold state, plan files and logs, and whether any backup copy leaves that boundary.

Hosting and operating model

Terrakube is a platform you install with a Helm chart or Docker Compose. Your team, or a partner such as DeployOpen, owns the cluster, upgrades and the on-call rotation that HCP Terraform currently carries for you. Ask who is paged when a run queue stalls at 2 a.m., and write that answer into the operating model before cutover.

Your database, storage and TLS

Terrakube runs on a relational database that Liquibase supports, such as PostgreSQL, MySQL, Oracle or SQL Server. You must supply that database, the object storage it uses, and the TLS certificates for the API hostname that terraform login targets. Each of these needs its own backup, rotation and restore test, because none of them is provided by the vendor.

Identity, groups and access

Terrakube authenticates through Dex, which federates identity providers such as Azure Active Directory, Amazon Cognito, GitHub and SAML. Permissions on workspaces, modules and VCS connections are assigned by group. Map your existing HCP Terraform teams to these groups before migration, and confirm that the group claims your identity provider sends are enough for least-privilege access.

Client-side encryption in OpenTofu

OpenTofu can encrypt state and plan files on the client, both locally and at remote backends, using key providers such as AWS KMS, GCP KMS, OpenBao and Azure Vault. This means the stored file is ciphertext even if the storage layer is read by someone else. Decide which key provider you will use, who owns the keys, and how key rotation is recorded, because losing the key means losing the state.

Audit evidence and shared duties

DeployOpen plans, implements and documents the controls, logging and evidence collection for your self-hosted stack, and prepares it for assessment. It does not issue audit reports or certifications; independent auditors and certification bodies do that. Agree in writing which party owns patching, backup restore tests and log retention, so the evidence an auditor requests can be produced from your own systems.

Who pays for what: HCP Terraform subscriptions and Terrakube operations

HCP Terraform bills paid tiers per managed resource, so the invoice tracks the number of resources your workspaces manage rather than the number of engineers with access. The HashiCorp pricing page lists Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per resource per month. The legacy Free plan reached end of life on March 31, 2026, and remaining organizations moved to the enhanced Free tier of up to 500 managed resources with unlimited users, according to HashiCorp's blog.

  • Per-resource rates: Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per managed resource per month, as listed by HashiCorp.
  • Free tier ceiling: Up to 500 managed resources with unlimited users, which becomes the boundary to watch as state grows.
  • Recurring charge: The subscription bills for as long as workspaces hold resources, so the cost repeats every month.
  • Tier drivers: Resource count and the features you need decide the tier. Confirm which features each tier includes before you commit.
  • Counting rules: Ask HashiCorp to confirm which resources count toward the managed total for your configurations, including modules.

Before comparing totals, check the current rate card and count managed resources per workspace in your own state.

What changes when you run OpenTofu instead of BSL Terraform

The first decision is licensing. On August 10, 2023, HashiCorp announced that 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. Terraform releases under the BSL are the ones your team would otherwise keep running on HCP Terraform or Terraform Enterprise. OpenTofu is an MPL-2.0 fork under the Linux Foundation, created by a group including Gruntwork, Spacelift and Harness, and it was accepted to the CNCF Sandbox on April 23, 2025. If your organization has a license policy that excludes source-available terms, or a vendor neutrality requirement for the IaC toolchain, this change matters regardless of how well the platform works.

OpenTofu is positioned as a drop-in replacement that preserves existing workflows and configurations, which is why the switch is usually a binary swap rather than a rewrite. In practice, the reader should confirm three things before committing. First, check which Terraform version each workspace state was written with, because state and provider behavior must be verified after the switch. Second, check whether any configuration uses features that OpenTofu has added or changed since the fork, such as early evaluation of variables and locals added in v1.8. Third, decide how the CLI version is pinned in your repositories and in the Terrakube or Atlantis runner images, since the cloud block and remote backend depend on the client version your runners use.

The main caveat is that OpenTofu does not guarantee compatibility with future Terraform releases. The project aims to keep feature parity with Terraform while its community decides which features to adopt, so a future Terraform feature may not arrive in OpenTofu on the same schedule, or at all. OpenTofu v1.13.1 was released on October 1, 2026, and the team should pin the exact OpenTofu version in every workspace and runner, record the version in change management, and test upgrades in a non-production workspace with a plan that must show no unexpected diffs before promotion. Ask whether your provider and module sources have been tested against the pinned OpenTofu version, since the OpenTofu Registry lists more than 3,900 providers and 23,600 modules.

What a move from HCP Terraform to Terrakube involves

The sequence moves each workspace's code, state, variables and access model from HCP Terraform into Terrakube, then proves the result with a small change before any cutover decision on OpenTofu.

  1. Inventory workspaces, variables, VCS links and teams

    Before touching anything, list every organization, workspace, variable set, VCS connection, team and private registry module in HCP Terraform. Note which workspaces use the cloud block, the remote backend or CLI-driven runs, and which depend on terraform_remote_state from other workspaces. Your platform lead or the team owning each workspace should sign off on the inventory. It is done when every workspace has an owner and a row in a migration tracker that records its state source and access rules.

  2. Back up code and download current state

    Snapshot the configuration repositories each workspace reads from and record the commit each workspace currently applies. Then download the latest state through the state versions API. For states created by Terraform 1.3 or later, use the JSON state download URL, and keep the raw state as a second copy. Store both in access-controlled storage and confirm a checksum matches before you rely on the copy. Done means you can restore each workspace's state file from your own backup without HCP Terraform access.

  3. Stand up Terrakube with Helm or Docker Compose

    Deploy Terrakube in your own cluster using the Helm chart or Docker Compose, with a supported relational database such as PostgreSQL, and wire up Dex to your identity provider. Platform engineers usually handle this, and DeployOpen can run it as a fixed-scope implementation if you prefer. Use minikube or a similar local cluster to test the install before production. It is done when the Terrakube API responds, a test user can sign in through Dex, and a sample workspace completes a plan.

  4. Recreate organizations, workspaces, variables and group permissions

    Create the matching organization and workspaces in Terrakube, then re-enter variables, including sensitive values from your secrets store, rather than expecting an export. Connect VCS providers such as GitHub, GitLab, Bitbucket or Azure DevOps and rebuild team access as group permissions on workspaces, modules and VCS connections. Some HCP Terraform objects have no export path and must be re-created by hand, so record each one. It is done when a reviewer compares the two inventories and every workspace has matching variables, access and VCS links.

  5. Point the backend at Terrakube and run a small change

    Switch each configuration's cloud block or remote backend to the Terrakube API hostname, then authenticate with terraform login. Import or migrate the downloaded state into the new backend and confirm the state serial and resource list match the source. Apply a small, reversible change, such as a tag update, and check that the plan shows no unexpected drift. Done means the plan from the Terrakube run is clean, the apply succeeds and the change is visible in the run history.

  6. Decide on OpenTofu now or later

    Choose whether to keep Terraform under its Business Source License for the cutover or switch the CLI to OpenTofu at the same time or later. OpenTofu's migration overview describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, and test with a small change, described as designed to be safe and reversible. Review terraform_remote_state consumers first, since that data source typically needs extra care during migration and the overview links a separate guide for it. Done means a written decision per workspace, with the rollback path recorded.

Questions buyers ask before moving from HCP Terraform to Terrakube

How much effort does moving from HCP Terraform to Terrakube take?

The effort scales mainly with the number of workspaces, how many VCS connections and teams need to be recreated, and how much policy logic has to be translated. A small estate with a few workspaces, one VCS provider and simple team roles is a bounded piece of work. A large estate with many workspaces, several VCS providers, module dependencies and Sentinel policies takes longer because each workspace needs its state moved, its variables re-entered and its runs verified. Ask the vendor or the engagement lead to inventory these four things before quoting: workspaces, VCS links, teams and policy sets.

How long does a migration from HCP Terraform to Terrakube usually take?

No fixed duration applies to every estate, so treat any single number as unverified until your own inventory is complete. Timing is lengthened by a large workspace count, state that needs careful locking during cutover, cross-workspace data sharing through remote state, identity provider setup that needs approvals, and a platform that must be installed and hardened before any run is allowed. A fixed-scope written agreement sets the schedule and deliverables before work starts, so ask for the milestones and the acceptance tests for each workspace.

What does our team need to provide for a Terrakube migration?

Your team needs to supply or approve several things before work starts:

  • Cloud accounts or data center capacity where Terrakube and its database will run.
  • Ownership of the PostgreSQL or other supported relational database, backups and TLS certificates for the Terrakube API hostname.
  • An administrator for your identity provider, since Terrakube uses Dex for SSO and group-based permissions.
  • A test workspace that is not production, so runs and state moves can be checked before cutover.

Also confirm who approves changes to group mappings and who holds the keys used for any state encryption.

Can our own engineers migrate to Terrakube without outside help?

Yes, a capable platform team can move a small estate alone, since the documented path covers state download through the state versions API, pointing the cloud block or remote backend at Terrakube, and re-creating variables and VCS links. The harder parts are operating the platform, translating policies and proving every workspace behaves the same afterward. Teams without experience running a multi-service platform with a database, identity integration and TLS often choose to bring in an implementation partner for the install, hardening and cutover. DeployOpen implements, hardens and documents self-hosted platforms in the client's own infrastructure under written, fixed scope.

What recurring work does a self-hosted Terrakube need after go-live?

Terrakube is a running service, so someone must own its upgrades, database and state backups, monitoring, access reviews and the extensions you depend on. Upgrades follow the Terrakube release cycle, and you should test each one in a non-production environment before rolling it out. Backups must cover the relational database and any state storage, and you should rehearse a restore. Monitoring should alert on failed runs, database health and certificate expiry. These tasks can stay with your team, or they can sit under a support retainer that covers upgrades and continuous checks.

Does Terrakube support HCP Terraform run tasks and Sentinel policies?

Terrakube does not provide Sentinel or HCP Terraform run tasks as a drop-in feature, so confirm this against the current Terrakube documentation before you rely on it. Its extension model includes OPA policy checks and Infracost cost estimates, and its API supports custom integrations. Sentinel rules must be rewritten as Rego and tested against your plans, and any HCP run task that calls an external service will need a matching integration built and approved in your environment. Ask for a policy inventory with each rule mapped to an OPA equivalent or a documented exception.

What should a fixed-scope quote for this migration include?

A fixed-scope quote should name the workspaces, VCS connections, identity groups and policies in scope, plus the environments where Terrakube will be installed. Ask for each deliverable to be listed with its acceptance test, including a state-match check for every migrated workspace and a documented cutover and rollback plan. Confirm who hardens the platform, who holds backups, what support is included after go-live and whether OpenTofu replaces Terraform in the same change. DeployOpen does not publish a price list, so the quote follows from the written scope.

Is OpenTofu a safe replacement for Terraform during this move?

OpenTofu is designed as a drop-in replacement for Terraform, and its migration guide describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, and test with a small change. The guide describes the process as safe and reversible. Compatibility with future Terraform releases is not guaranteed, because the OpenTofu project decides which features it adopts. Configurations that use terraform_remote_state need extra care during migration, so review those workspaces separately before switching.

How DeployOpen helps you evaluate, implement and migrate

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For HCP Terraform vs Terrakube, we start from your organization, workspace, registry and identity model, then build and hand over a Terrakube deployment running OpenTofu or Terraform in your own cloud account, data center or air-gapped network.

How we scope

  • Inventory your HCP Terraform organizations, workspaces, VCS connections, teams and private registry modules before any design work starts.
  • Agree in writing which workspaces move, which stay on HCP Terraform during a parallel run, and which IaC CLI you will use.
  • Confirm identity requirements for Dex, group-based permissions and any OPA policy checks Terrakube must run during plans.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and no price list is published.

How we build

  • Deploy Terrakube with the Helm chart or Docker Compose in your environment, with a database supported by Liquibase such as PostgreSQL.
  • Configure remote backend and cloud block access for the Terraform or OpenTofu CLI, and test login against the Terrakube API hostname.
  • Connect GitHub, GitLab, Bitbucket or Azure DevOps repositories and wire OPA policy checks through Terrakube extensions.
  • Test representative runs end to end, then document configuration, access groups and the operational runbook for your team.

How we hand over

  • Deliver written configuration, architecture notes and a per-workspace migration checklist covering state, variables and VCS links.
  • Walk your platform and security engineers through run operations, group permissions, backup and upgrade procedures.
  • Document the terraform_remote_state dependencies that need extra care when you switch the CLI to OpenTofu.
  • Provide evidence of configuration and access controls that your internal or external assessors can review.

How we support

  • Ongoing support, upgrades and continuous security testing are available as retainers after handover.
  • Plan Terrakube version upgrades and OpenTofu CLI upgrades against your own test workspaces before production rollout.
  • Keep backups of the Terrakube database and state storage tested, with restore steps documented for your environment.
  • DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com