Is HCP Terraform cost vs self-hosted Terrakube a cheaper trade?
Self-hosting Terrakube tends to cost less than HCP Terraform only when your managed resource count and user base grow past what the hosted tiers price comfortably, and when you already have a platform team that can absorb the operating work. HashiCorp bills paid HCP Terraform tiers per managed resource at $0.10 (Essentials), $0.47 (Standard) and $0.99 (Premium) per resource per month, according to the HashiCorp pricing page, while Terraform Enterprise, the self-managed edition, is custom priced and needs a quote. Terrakube itself carries no license fee, so the comparison is really between a metered subscription and the infrastructure and staff time you would otherwise not spend. The answer depends on three variables: how many managed resources your workspaces hold, how many users need access, and how much engineering time the self-hosted platform consumes. Count managed resources across every workspace you would migrate, not just the busiest ones, and check the current enhanced Free tier limit of 500 managed resources against that count. For the self-hosted side, list the cost components: compute for the Terrakube API, UI, executor and database (Terrakube supports PostgreSQL and other Liquibase-supported databases), state storage in an object store, backups, upgrades, identity integration, and the people who patch and monitor it. Ask your implementation partner for a fixed-scope quote that separates one-time setup from recurring operations, and ask Terrakube's maintainers or your cloud provider to confirm current infrastructure requirements before you size anything.
Before you commit to a tier change or a self-hosted build, run a short cost model for your own estate. Pull the managed resource count per workspace, the number of named users, and the number of runs per month, then price each scenario: staying on the paid HCP Terraform tier, moving to Terrakube, or moving to Atlantis if your team reviews infrastructure in pull requests and does not need a run UI or registry. Atlantis has no managed state or registry, so its state backend and any module hosting are costs you carry yourself. Terraform Enterprise quotes should be compared on the same basis, and you should ask the vendor to state what the quote includes for support, upgrades and seats. For a self-hosted route, the recurring costs are usually larger than the first deployment. Budget for ongoing upgrades to Terrakube and OpenTofu, security patching of the platform and its database, backup and restore testing, and on-call coverage for failed runs. Those tasks fall on a platform team whose time has a real price even when no invoice arrives. If the tier decision is driven by data residency or lock-in rather than price, a self-hosted build can be justified even when the monthly numbers are close, but make that judgment explicitly and record it in the renewal decision.
Which cost components move between HCP Terraform and self-hosted Terrakube
This table compares each cost component on the HCP Terraform side with its counterpart under a self-hosted Terrakube or Atlantis setup, marking whether each item is one-time or recurring. Read it as a checklist for building a quote, since most self-hosted costs come from people and infrastructure rather than software licenses. Terrakube and Atlantis are both Apache 2.0 and OpenTofu is MPL-2.0, so no software license fee applies on the self-hosted side.
| Cost component | HCP Terraform or Terraform Enterprise | Self-hosted Terrakube or Atlantis |
|---|---|---|
| Subscription or license | Per managed resource tiers on HCP Terraform, or custom-priced Terraform Enterprise (recurring) | No software license fee: Terrakube and Atlantis are Apache 2.0, OpenTofu is MPL-2.0 (recurring cost is zero) |
| Infrastructure | Included in the hosted service (recurring) | Compute for the run platform, a relational database, object storage for state and backups (recurring) |
| Implementation | Largely vendor-configured onboarding by your team (one-time, internal effort) | Install, identity integration through Dex, VCS connections and networking (one-time, scoped in writing) |
| Migration | Export state through the state versions API, then re-create variables and teams (one-time) | Same export work plus validating each workspace before cancelling the old service (one-time) |
| Support | Vendor support tied to your contract level (recurring, confirm terms in your agreement) | Internal on-call or a retainer with an implementation partner, plus community channels (recurring) |
| Upgrades and patching | Handled by the vendor on the hosted service (recurring, included) | Terrakube, Atlantis, OpenTofu and the database need scheduled upgrades and testing (recurring) |
| Internal skills | Platform team needs Terraform and VCS administration knowledge (recurring) | Platform team also needs Kubernetes or container operations, database administration and backup restore testing (recurring) |
| Security evidence | Vendor documentation and shared responsibility terms (recurring, confirm with the vendor) | Your team produces configuration, access and backup evidence for assessors (recurring) |
What pushes the self-hosted cost up or down
On HCP Terraform, the bill follows managed resources and tier choice, so resource count is the main lever. On self-hosted Terrakube or Atlantis, the bill follows the infrastructure you run, the people who run it and the availability you need, so these factors shift the comparison in different directions.
Managed resource count
HCP Terraform's paid tiers bill per managed resource per month, so resource count is the first number to measure. The enhanced Free tier covers up to 500 managed resources, and the paid tiers are listed at $0.10, $0.47 and $0.99 per resource per month for Essentials, Standard and Premium. Count resources across every workspace in your current plan output, then project growth over the next renewal cycle. Self-hosted Terrakube or Atlantis does not charge per resource, so its cost does not rise with that count, but your compute and state storage may.
Users and workspaces
On the enhanced Free tier, users are not the limit, so a large team can work inside the resource cap without adding seats. Resource count is therefore the constraint that matters there, not headcount. On a self-hosted stack, user count mainly affects identity integration, group mapping and support load, while workspace count drives database size, runner concurrency and the number of pipelines to maintain. Ask how many concurrent runs your largest team starts during a normal change window.
VCS connections
Each repository or provider you connect to Terrakube, such as GitHub, GitLab, Bitbucket or Azure DevOps, adds webhook setup, credential rotation and access reviews. Atlantis adds a similar cost through its webhook and per-repository configuration in atlantis.yaml. Count the repositories that trigger infrastructure runs and the number of distinct credentials they need. Pull request automation can make this count grow faster than the team expects.
State data volume
State size and history determine how much storage you keep, how long backups take and how quickly a plan starts. Migration also requires downloading current state through the state versions API, so large or many workspaces add transfer and verification time. Atlantis cannot use local state, so you must pick and run a remote backend such as S3 or GCS, which adds its own storage cost. Check state sizes per workspace before choosing an instance size.
Availability and backup requirements
HCP Terraform handles hosting, uptime and state durability for you under its service terms. A self-hosted deployment makes those obligations yours, including high availability for the API and database, tested restores and retention that matches your audit policy. Each of these adds infrastructure, licensing for any managed database and time for drills. Confirm your recovery objectives with the business owner before you size the cluster, and ask any implementation partner to price restore testing as its own line item.
Skills already on the team
Operating Terrakube or Atlantis needs people who can run Kubernetes or Docker, manage a relational database, configure identity through Dex or SSO and troubleshoot runner failures. Teams with that experience absorb the work into existing duties, while teams without it either hire or buy support. This is usually the largest recurring cost in the comparison, so count the engineer hours per month for upgrades, patching and on-call. Ask a partner for a written scope that names who does each task before you compare totals.
How to build the cost comparison with your own numbers
This sequence turns the pricing model into a side-by-side comparison built from your own workspace count, state size and team hours, so the result reflects your environment rather than a generic estimate. Each step names the input it produces and the source that must confirm it.
Count managed resources per workspace
Start from the current state of every HCP Terraform workspace, not from the code. Pull each workspace's state through the state versions API, or list resources with your own tooling, and count the managed resources in each one. Data sources and resources you do not manage are not billed as managed resources, so confirm the counting rules against HashiCorp's current documentation before you rely on the totals. Your output is a table of workspace name, managed resource count and owning team, with a total at the bottom. Check the total against a second method, such as a state listing, before you move on.
List paid tiers and per-resource prices
Take the total from the first step and price it against each HCP Terraform tier. The HashiCorp pricing page lists Essentials at $0.10, Standard at $0.47 and Premium at $0.99 per managed resource per month, and those figures are the only prices in this comparison that come from a published source. Compare them with the enhanced Free tier limit of 500 managed resources, and note where your count crosses it. Record which features each tier includes, such as SSO, policy checks and private registry access, because a lower tier may leave out something your team depends on. Confirm current prices on the pricing page before you finalize the figures.
Request a Terraform Enterprise quote
Terraform Enterprise is priced by custom quote, so the only way to get a number is a written request. Send the vendor the same workspace count, the number of users, the deployment target (Docker, Kubernetes or OpenShift), the support level you need and the term you expect. Ask what is included in the subscription, how renewals are priced, and whether support or upgrade assistance is extra. Ask for the quote in writing with the scope attached. Your output is a quote document you can line up against the open-source column, and it should be marked as the only Terraform Enterprise input in this comparison.
Price Terrakube or Atlantis infrastructure and storage
The open-source software is free under Apache 2.0, so this step prices the infrastructure to run it. List the Kubernetes cluster or Docker hosts, the PostgreSQL or other supported relational database that Terrakube needs, the object storage or state backend, backups, load balancing and monitoring. For Atlantis, list the pod or container capacity and the state backend such as S3 or GCS. Ask your cloud or data center team for the unit costs in your own accounts, since these depend on region, instance types and contracts. Your output is a monthly and annual infrastructure line for each option, with each component named.
Estimate migration and setup hours
Estimate setup and migration effort in your own team's hours, not in a generic figure. Break the work into installing the platform, configuring identity and VCS connections, recreating variables and teams, moving state for each workspace, changing the cloud block or remote backend, and switching to OpenTofu where you choose to. Assign hours to each item by workspace group, and add time for testing with a small change in each one. The OpenTofu migration overview describes a four-step process of backing up state and code, installing OpenTofu, initializing and verifying the configuration, and testing with a small change, so use those phases as your checklist. Your output is an hours table with a named owner per row, and a separate line for any work you outsource under a written scope.
Assign platform engineer time for operations
The recurring cost is usually the platform team. Estimate the share of platform engineer time for upgrades to Terrakube or Atlantis, OpenTofu releases, database and backup maintenance, identity changes, on-call response and user support. Express this as a percentage of named people's time, and cost it at your own loaded rate. Do the same for the HCP Terraform or Terraform Enterprise side, where the vendor's time is part of the subscription but your administrators still manage users, workspaces and integrations. Your output is an annual operations line for each option. This is the input most often left out, and it is the one that changes the comparison most when the team is small.
Compare totals and set a review date
Bring the outputs together in one table: subscription or licensing for each option, infrastructure, one-time migration hours and recurring platform engineer time. Separate one-time costs from recurring ones, and show the first-year total alongside the steady-state annual total. Test the result by changing the two inputs most likely to move, the resource count and the platform engineer share, and see where the ranking changes. Record which lines came from a vendor quote, which from your own cloud invoices and which from your own estimates, so the review can be repeated. The finished table is the input for a decision, and it should be reviewed again when the resource count or pricing changes.
What each HCP Terraform option charges for
Essentials is the entry paid tier of HCP Terraform, listed at $0.10 per managed resource per month on the HashiCorp pricing page. It is the usual step for a small team that has outgrown the enhanced Free tier of up to 500 managed resources and needs the hosted run and state service with a modest feature set. The bill follows the number of resources your configurations manage, so the total is driven by infrastructure size rather than by headcount.
- List price: $0.10 per managed resource per month, as published by HashiCorp.
- Recurring cost: the charge repeats every month for each counted resource, so it behaves as an ongoing operating expense.
- Resource counting: confirm which resource types count, how replaced or destroyed resources are treated and whether data sources are included.
- Users, teams and SSO: confirm the user, team and single sign-on limits that apply at this tier.
- Support: confirm the support level and response expectations included in the plan.
Before modelling, check the current feature table and the resource counting rules on the pricing page, then multiply your counted resources by the monthly rate.
Standard is the middle paid tier, listed at $0.47 per managed resource per month on the HashiCorp pricing page. Teams usually move up to it when several groups share workspaces and need more controls over who can run and approve changes. The per-resource rate is the main cost driver, so the same estate costs more at this tier than at Essentials, and the gap grows with every resource added.
- List price: $0.47 per managed resource per month, as published by HashiCorp.
- Illustrative scale: at 200 counted resources, the list rate alone would be $94 per month before any other charges.
- Added capabilities: confirm which collaboration, access control and governance features move from the lower tier to this one.
- Limits: confirm workspace, run concurrency and user limits, since these can force a move to a higher tier before resource counts do.
- Support and onboarding: confirm which support channels and onboarding help are included.
Before modelling, compare the Standard feature list line by line against the controls your auditors and security team require, and confirm any limit that could trigger an upgrade.
Premium is the highest paid per-resource tier, listed at $0.99 per managed resource per month on the HashiCorp pricing page. It is typically chosen by organizations that need the most advanced governance, policy and support options that HashiCorp offers in the hosted service. At this rate the per-resource cost is roughly double the Standard list price, so the decision to select Premium should rest on a documented requirement rather than convenience.
- List price: $0.99 per managed resource per month, as published by HashiCorp.
- Illustrative scale: at 200 counted resources, the list rate alone would be $198 per month before any other charges.
- Governance features: confirm which policy, audit and access features are included and whether they match your control requirements.
- Support terms: confirm response times, severity definitions and any dedicated contacts included.
- Commitment terms: confirm whether annual or multi-year terms change the effective rate and what renewal increases are allowed.
Before modelling, ask HashiCorp to confirm in writing which features your team depends on at this tier and whether any of them are available in a lower plan.
Terraform Enterprise is the self-managed edition of HCP Terraform and is custom priced on the HashiCorp pricing page, so no list figure applies. The cost has two parts: the license quoted by the vendor and the infrastructure you run it on, which includes compute, a database, object storage and the people who install, upgrade and back it up. Because the license is quoted, the only reliable way to compare it with Terrakube or Atlantis is to request a written quote for your scope.
- License basis: ask whether the quote is based on managed resources, users, instances or another unit, and how it changes as you grow.
- Infrastructure: ask the vendor to list the hosting components and sizing it expects, then price them in your own cloud or data center.
- Operations: estimate who patches, upgrades and backs up the installation and what that staff time costs internally.
- Renewal and term: confirm the contract length, renewal uplift and what happens to data and access if the subscription ends.
- Support: confirm the support tier, included upgrades and any separate charges for professional services.
Before comparing, put the Terraform Enterprise quote, the infrastructure bill and internal operations time in the same annual model as the Terrakube or Atlantis option.
How the 500-resource Free tier changes the HCP Terraform cost math
The legacy HCP Terraform Free plan reached end of life on March 31, 2026, and remaining organizations were moved automatically to the enhanced Free tier, which HashiCorp describes as up to 500 managed resources with unlimited users. For many teams the practical effect is that the cost question has moved from users to resources. Seat count no longer drives the bill at the free level, so the decision now depends on how many managed resources your workspaces create and keep alive.
Whether growth forces a paid tier depends entirely on how managed resources are counted in your own account. HCP Terraform bills paid tiers per managed resource, listed at $0.10 for Essentials, $0.47 for Standard and $0.99 for Premium per resource per month, according to the HashiCorp pricing page. Ask HashiCorp or your account team to confirm which resource types count, whether data sources and modules are excluded, and how a resource that is destroyed mid-month is billed. Then run a count across every workspace and compare it with the 500 limit, including planned environments that will be created in the next budget period.
Self-hosted OpenTofu with Terrakube or Atlantis is usually the cheaper path when resource counts grow past the Free tier and the platform team already runs Kubernetes or similar infrastructure, because the license cost does not scale with resources. The costs move to infrastructure, a relational database, state storage and the people who operate the stack. Those costs are recurring and depend on your environment, so request a written scope and estimate from DeployOpen and your cloud provider before deciding. If your count stays comfortably under 500, staying on the Free tier may remain the lowest-cost option for now.
What do buyers ask about HCP Terraform cost and self-hosting effort?
What does running a self-hosted Terrakube or Atlantis cost compared with HCP Terraform?
The software itself carries no license fee, because Terrakube and Atlantis are both Apache 2.0 and OpenTofu is MPL-2.0. The comparison is therefore between HCP Terraform's per-managed-resource billing and your own running costs. Those running costs have four parts: compute and a relational database for Terrakube (it supports PostgreSQL, MySQL, Oracle and SQL Server), or compute for Atlantis, plus state storage in your own backend, plus the engineering time to install, upgrade, back up and secure the platform. HCP Terraform's paid tiers are priced per managed resource, at $0.10, $0.47 and $0.99 per resource per month for Essentials, Standard and Premium, according to HashiCorp's pricing page, so its cost grows with your resource count. Self-hosted costs grow more with the number of teams and environments you operate. Ask your team to model both against your actual resource count and platform headcount.
Does the 500-resource Free tier change the cost math for my team?
It can, depending on how many managed resources you run. HashiCorp announced on December 17, 2025 that the legacy Free plan would end on March 31, 2026, and remaining organizations were moved to the enhanced Free tier of up to 500 managed resources with unlimited users. Below that ceiling, the hosted service costs nothing in licensing. Above it, you move to a paid tier billed per managed resource. Count resources in your largest workspaces first, because a single large module can add many of them. Self-hosting removes the resource ceiling but not the operating work, so a small estate may stay on the Free tier longer than it is worth running your own platform.
How long does a migration from HCP Terraform to Terrakube or Atlantis take?
The supplied sources do not give a duration, so treat any number you hear as unverified until it is tied to your scope. Time depends on the number of workspaces, whether each workspace's state can be exported cleanly through the state versions API, how many variables, VCS links and teams must be re-created by hand, and whether you also switch to OpenTofu at the same time. Atlantis adds work for state backend selection and atlantis.yaml files, while Terrakube adds database and identity provider setup. Ask for a workspace inventory and a per-workspace plan before accepting any timeline. Most engagements are fixed-scope, so DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Can our own engineers run the migration without outside help?
Often yes, if your team already operates Kubernetes or Docker, manages a state backend and reviews infrastructure code in pull requests. Terrakube documents installation with a Helm chart or Docker Compose, and Atlantis documents a Helm chart, Kustomize, Docker and several other deployment options. The harder work is the cutover: exporting state safely, confirming that a plan shows no unexpected changes, and handling terraform_remote_state consumers, which the OpenTofu migration guide flags for extra care. Be honest with your team about how much of that they have done before. Many organizations split the work: internal staff own the day-to-day platform, while an outside team handles the first installation, the cutover or the hardening. DeployOpen can take on any of those parts under a written scope.
What does the platform team need to keep Terrakube or Atlantis running?
The platform needs named owners for these recurring tasks:
- Upgrades of the run platform, tracked against the Terrakube GitHub releases or the Atlantis GitHub releases page
- Upgrades of the IaC CLI, whether OpenTofu or Terraform, with checks that each version still plans cleanly
- Database and state backup, plus tested restores
- Identity configuration through Dex, group-based permissions on workspaces, modules and VCS connections, and access reviews
- Monitoring of runners, webhooks and locks, including stale locks in Atlantis
- Security patching of the container images and the hosting cluster
Determine who owns each item before go-live. The staffing level depends on how many teams use the platform and how often they change infrastructure.
How do I get a Terraform Enterprise quote?
Terraform Enterprise is the self-managed HashiCorp edition, and HashiCorp lists its pricing as custom, so there is no public figure to compare against. Contact HashiCorp or IBM through their sales channels to request a quote. Ask the vendor to state the unit it bills on, the resource or user count it assumes, the support level included, what happens at renewal, and whether upgrades, hosting and backups are included. Then compare that quote with your own total cost: infrastructure, database, storage, the platform team's time and the cost of any outside support you choose to buy. Keep the quote in writing so the comparison stays tied to the same scope.
Does switching to OpenTofu add cost to the migration?
OpenTofu is MPL-2.0 licensed, so using it does not add a license fee. It is a drop-in replacement for Terraform that keeps existing workflows and configurations, and the migration overview describes four steps: back up state and code, install OpenTofu, initialize and verify, then test with a small change. The additional work is verification and, where you use them, configuration of state and plan encryption with a key provider such as AWS KMS, GCP KMS or OpenBao, which the OpenTofu documentation describes. Costs there come from your key management service and the time to set policies. Compatibility with future Terraform releases is not guaranteed, so check each upgrade against your own modules and providers.
How DeployOpen works on this
DeployOpen starts with a written scope that compares your current HCP Terraform spend, managed resource count and workspace layout with the infrastructure, state storage and platform roles a self-hosted Terrakube or Atlantis setup would need. Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts.
How we scope
- We inventory workspaces, managed resources, VCS connections, teams and variables so the written scope reflects your real footprint.
- We confirm whether you need the remote backend and cloud block, Atlantis pull request automation, or both, and which CLI version each team uses.
- We agree the cost model with you, listing hosting, state storage, database, identity and staff effort, and the quote follows from that written scope.
How we build
- We deploy Terrakube with its Helm chart or Docker Compose in your cloud account or data center, connected to your chosen relational database.
- We configure Dex with your identity provider, map groups to workspace, module and VCS permissions, and set up the state backend you approve.
- We set up OpenTofu as the CLI in pipelines and runs, and test the configuration with a small change in a non-production workspace before any cutover.
How we hand over
- We document the architecture, backup and restore steps, upgrade procedure and the state migration record for each workspace moved.
- We walk your platform team through daily operations, including run troubleshooting, lock handling and how to add a workspace or module.
- We provide the cost and ownership summary your finance and procurement teams need to compare the self-hosted run against the HCP Terraform bill.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so you choose how much of the platform DeployOpen operates.
- We can keep the platform current with new Terrakube and OpenTofu releases, reviewing changes in the written scope before applying them.
- Security testing of the deployed platform and its access paths can be scoped as a separate engagement, with findings delivered in writing.
