Last updated: April 2026

If you searched for "Terraform Cloud" and ended up here, you're not alone in being a little confused. The product still exists: HashiCorp (now an IBM company) rebranded it to HCP Terraform in April 2024. The core feature set is largely the same, but a lot has changed since then. The pricing model was overhauled, the long-standing free tier ended March 31, 2026, IBM completed a $6.4 billion acquisition, and OpenTofu has emerged as a genuinely competitive open-source fork.

If you set up a Terraform Cloud account two years ago and haven't looked closely since, this post will catch you up. We cover what HCP Terraform actually does, how the 2026 pricing tiers work, what the IBM acquisition means in practice, and where env zero fits for teams who want something more flexible.

HCP Terraform (formerly Terraform Cloud) is HashiCorp's SaaS platform for running Terraform at scale, providing remote execution, state management, policy enforcement, and team collaboration. Current stable Terraform version:
(March 2026). IBM acquired HashiCorp in February 2025 for $6.4 billion. The legacy free tier ended March 31, 2026, replaced by a new Free plan covering 500 managed resources. Pricing tiers: Free, Essentials ($0.10/resource/month), Standard ($0.47/resource/month), Premium ($0.99/resource/month), and Terraform Enterprise (self-managed).

From Terraform Cloud to HCP Terraform: what changed

The rename is the most visible change, but there's meaningful context behind it. In August 2023, HashiCorp switched Terraform's license from Mozilla Public License 2.0 to the Business Source License (BSL). Under BSL, anyone embedding Terraform functionality into their own product, offering it as a managed service, or reselling it needs a commercial license. The community responded quickly: OpenTofu launched in September 2023 as a fully open-source fork under the OpenTF Foundation, was accepted into the CNCF as a sandbox project in April 2025, and now reports 9.8 million downloads with 300% annual growth. According to a Spacelift Q4 2024 survey, roughly 38% of Terraform users are actively evaluating or migrating to OpenTofu.

The rebrand from "Terraform Cloud" to "HCP Terraform" reflects HashiCorp's broader push to unify its products under the HashiCorp Cloud Platform (HCP) umbrella, alongside HCP Vault, HCP Consul, and HCP Packer. That pivot was still in motion when IBM completed its $6.4 billion acquisition of HashiCorp on February 27, 2025. IBM's stated rationale was strengthening its hybrid cloud portfolio and integrating HashiCorp's tooling with Red Hat Ansible.

What does IBM ownership mean for you today? Practically, not much has changed in the product roadmap. HashiCorp continues to ship features under IBM. The BSL license remains. But the acquisition uncertainty was real motivation for many teams to evaluate OpenTofu, and the free tier discontinuation pushed more of those evaluations to completion.

is a good next read if you want the full ecosystem view: where HCP Terraform, OpenTofu, Terragrunt, and managed platforms each fit.

What HCP Terraform does

HCP Terraform is a platform that runs Terraform operations remotely and provides the collaboration layer that plain Terraform OSS doesn't. The core value is not the execution engine itself. Terraform does that fine locally. The value is the organizational layer around it: shared state, team access controls, policy enforcement, a private module registry, and a predictable execution environment that isn't a developer's laptop. For a detailed comparison of private registry options across platforms, see our Terraform Registry guide.

Workspaces and runs

A workspace in HCP Terraform maps to a single Terraform root module configuration. Each workspace maintains its own state, variables, and run history. Runs are triggered via VCS integration (automatically when you push or open a pull request), from the CLI with terraform plan or terraform apply, or through the API for programmatic pipelines.

VCS-driven workflows are the most common starting point: connect a GitHub or GitLab repository, and HCP Terraform watches for commits and PRs, triggering speculative plans on pull requests and applies on merge to your default branch.

Remote state is stored and encrypted in HCP Terraform's backend. Other workspaces can read outputs using terraform_remote_state data sources, which enables workspace-to-workspace dependencies without sharing credentials or state files manually.

Projects

Projects group workspaces together and apply permissions at the group level. This matters at scale: instead of managing RBAC workspace by workspace, you can grant a team access to a project and all workspaces within it inherit those controls.

Policy enforcement

HCP Terraform supports two policy-as-code systems: Sentinel (HashiCorp's proprietary policy language, available on paid plans) and Open Policy Agent (OPA), available on all plans including Free. The Free plan limits you to one policy set of up to five policies. A failing hard-mandatory policy blocks the apply; policies run between the plan and apply stages.

Run Tasks

Run Tasks let you integrate third-party tools into the HCP Terraform run lifecycle. A Run Task calls an external endpoint before or after the plan or apply stage and can block the apply if the check fails. Common uses include security scanning (Snyk, Prisma Cloud), cost estimation (Infracost), and compliance validation via custom webhooks. The Free tier includes Run Tasks with a limit on active integrations; higher tiers remove that cap.

is a deeper look at writing and deploying OPA policies for Terraform.

Key features in 2026

Two years of feature releases. A few things stand out.

Stacks

Stacks are the biggest architectural addition since workspaces. Where a workspace manages a single root module, a Stack coordinates multiple components as a unit: networking, compute, and application layers that need to deploy and update together. Stacks use their own configuration files and a deployment configuration to target multiple environments. They address a real pain point: managing inter-component dependencies and orchestrating ordered applies across a complex infrastructure graph.

For teams managing more than a handful of interdependent workspaces, Stacks are worth understanding before manually wiring workspace triggers together.

Dynamic provider credentials

This is the feature that should make you retire static AWS access keys in HCP Terraform workspaces. HCP Terraform supports workload identity federation with major cloud providers, generating short-lived credentials per run instead of storing long-lived keys as workspace variables.

For AWS, the configuration requires these workspace environment variables:

TFC_AWS_PROVIDER_AUTH            = "true"
TFC_AWS_RUN_ROLE_ARN             = "arn:aws:iam::123456789012:role/hcp-terraform-role"
TFC_AWS_WORKLOAD_IDENTITY_AUDIENCE = "aws.workload.identity"



Your AWS IAM role trust policy references HCP Terraform's workload identity provider. With these variables set, you no longer need AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY as workspace variables; HCP Terraform generates credentials automatically per run. The TFC_AWS_PLAN_ROLE_ARN and TFC_AWS_APPLY_ROLE_ARN variables let you use separate, more restrictive roles for plan versus apply phases.

Drift detection

Drift detection periodically compares your workspace state against actual deployed resources. When something changes outside Terraform (someone modifies a security group rule in the AWS Console, for example), HCP Terraform flags it as drifted and generates a report showing exactly what changed. It's especially useful in environments where manual console access is still common.

No-code provisioning

No-code provisioning takes a different angle entirely. Platform teams can expose a curated module through a form-based UI, so an engineer can provision approved infrastructure (an S3 bucket, a database, a Kubernetes namespace) by filling out a form, no Terraform configuration required. The underlying module is controlled by the platform team; consumers just fill in the fields.

covers where HCP Terraform fits alongside Terragrunt, Pulumi, Crossplane, and other tools in a multi-IaC environment.

HCP Terraform pricing in 2026

The pricing model changed significantly, and the legacy free tier ended March 31, 2026.

The free tier change

The original HCP Terraform free plan had unlimited managed resources and was capped by user count. That plan was discontinued on March 31, 2026. Organizations on the legacy plan were automatically migrated to the new enhanced Free tier, which supports up to 500 managed resources with unlimited users.

500 resources sounds like a lot until you account for how Terraform counts them. A single EKS cluster with associated VPC, subnets, security groups, IAM roles, and node groups can easily consume 40-60 resources. A moderately sized AWS environment with three tiers across two regions will exceed 500 resources faster than most teams expect.

Before assuming you're safe, check your actual count:

terraform state list | wc -l



Run that across all your workspaces and add up the totals. The number is often 2-3x what teams estimate.

If your count exceeds 500 and you haven't upgraded, HCP Terraform will prompt you to select a paid plan. Existing runs continue during a grace period, but provisioning new resources will be blocked until you move to a paid tier.

Current tiers

HCP Terraform pricing is resource-based. Resources Under Management (RUM) counts every managed resource declared in your Terraform state files, calculated hourly at your peak count. Full details and a cost estimator are on HashiCorp's pricing page.

| Tier | Price | Resource cap | Key additions |
|---|---|---|---|
| Free | $0 | 500 RUM | Remote execution, VCS integration, private registry, OPA (1 set, 5 policies), Run Tasks, SSO |
| Essentials | $0.10/resource/month | None | Same features as Free, no resource cap |
| Standard | $0.47/resource/month | None | Sentinel policy framework, audit logging, enhanced team management |
| Premium | $0.99/resource/month | None | Priority support, SLAs, enterprise governance |
| Enterprise | Contract | N/A | Self-managed deployment, air-gap and compliance support |

To put the Standard tier in concrete terms: 1,000 managed resources runs roughly $470/month. A 5,000-resource environment hits $2,350/month. Some teams coming from the free tier are seeing their bill go from $0 to over $15,000/year, which is driving significant migration activity toward alternatives.

compares HCP Terraform with Spacelift, Scalr, env zero, and open-source options including Atlantis.

HCP Terraform vs. Terraform Enterprise vs. OpenTofu

These three are often confused because they share history. The right choice is primarily a question of hosting model, licensing, and your organization's risk tolerance around the BSL.

| | HCP Terraform | Terraform Enterprise | OpenTofu |
|---|---|---|---|
|
| SaaS (HashiCorp-managed) | Self-managed | Self-managed |
|
| BSL | BSL | MPL 2.0 (open source) |
|
| Remote, in HashiCorp's infra | Remote, in your infra | Local or your CI pipeline |
|
| Per resource (RUM) | Contract | Free (bring your own platform) |
|

HCP Terraform

The SaaS offering. HashiCorp manages the backend, state storage, and policy execution. You bring your Terraform configurations; HashiCorp runs everything else. The right choice for teams that want managed tooling for their Terraform operations.

Terraform Enterprise

The same core product, deployed in your own environment: on-premises, in a private cloud, or in an air-gapped data center. The use case is regulatory: if your compliance requirements prohibit state files from leaving your network, or if you need to run policy enforcement within your security boundary, Terraform Enterprise is the answer. It's priced by contract rather than resource count.

OpenTofu

A different bet entirely. It's the open-source fork with an MPL 2.0 license (no BSL, no commercial requirements), fully community-governed under the CNCF. OpenTofu maintains HCL syntax compatibility and state file compatibility with Terraform. Most providers continue to work without changes. The tradeoff: you manage your own execution environment (typically Atlantis, Spacelift, env zero, or a custom CI pipeline), and you're accepting that the community fork and the HashiCorp codebase will diverge over time. For teams already sensitive to the BSL or looking for long-term license predictability, OpenTofu is a serious option.

The practical difference today is small. The philosophical difference is significant.

To make the HCP Terraform workflow concrete, the next section walks through deploying an EKS cluster using VCS integration, the private module registry, and dynamic credentials together in a single workflow.

Getting started: deploying an EKS cluster through HCP Terraform

Here's a concrete workflow using HCP Terraform's VCS integration and the private module registry, updated for current Kubernetes and AWS module versions.

Module structure

We'll use a private module wrapping the public terraform-aws-modules/eks/aws module (currently at v21.17.1), giving the platform team control over which version and configuration options are exposed to consumers.

# main.tf
module "eks" {
 source  = "app.terraform.io/<YOUR_ORG>/eks/aws"
 version = "~> 21.0"   # pin to major version 21, allow minor updates

 region               = var.region
 cluster_name         = var.cluster_name
 cluster_version      = "1.32"
 instance_types       = ["m5.large"]
 vpc_cidr             = "10.0.0.0/16"
 cluster_min_size     = 1
 cluster_max_size     = 5
 cluster_desired_size = 2
}



The source path uses the private registry format: app.terraform.io/<org>/<module-name>/<provider>. The version = "~> 21.0" constraint allows patch and minor updates within major version 21, the safest default for a module your whole organization depends on. Supporting variables and outputs (cluster region, name, Kubernetes version, cluster endpoint) follow standard Terraform patterns and live in variables.tf and outputs.tf.

AWS credentials: use dynamic credentials, not static keys

Rather than adding AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as workspace variables, configure dynamic provider credentials. In your HCP Terraform workspace settings, add:

TFC_AWS_PROVIDER_AUTH  = "true"
TFC_AWS_RUN_ROLE_ARN   = "arn:aws:iam::<ACCOUNT_ID>:role/hcp-terraform-role"



Your AWS IAM role needs a trust policy that allows HCP Terraform's workload identity provider to assume it. The AWS dynamic credentials documentation walks through the exact trust policy JSON. Once configured, each Terraform run gets a short-lived credential scoped to that role, with no long-lived keys stored anywhere in HCP Terraform.

VCS workflow

Connect the workspace to your GitHub or GitLab repository. HCP Terraform will run a speculative plan on every pull request and post the results as a PR check. Merging to your default branch triggers the apply. The workflow is close to GitOps: the repository is the source of truth, and HCP Terraform enforces that a plan must pass before any apply.

One limitation worth knowing: HCP Terraform's VCS integration requires your repository to be reachable from HashiCorp's infrastructure. For teams running internal GitLab or private GitHub Enterprise behind a firewall, that means opening outbound connectivity or using self-hosted agents (available on paid tiers). If network exposure is a concern, plan for this before you're mid-rollout.

After the apply, update your kubeconfig and verify the cluster:

aws eks --region us-east-1 update-kubeconfig --name <cluster_name>
kubectl get nodes



You should see nodes in Ready state running Kubernetes 1.32.

Common pitfalls when running HCP Terraform at scale

Most of these are only apparent after an organization has been on the platform for a while.

Resource count surprises

RUM pricing counts every managed resource in your Terraform state files. Teams migrating from the legacy free plan often discover their resource count is 3-4x what they assumed. The most common shock we see: a team thinks they have 300 resources, runs terraform state list | wc -l across all workspaces, and lands at 1,400. Before committing to a tier, count first.

Workspace sprawl

The natural org pattern is one workspace per environment per service. In our experience, that scales well to around 50 workspaces. Past that point, workspace-level access management becomes unwieldy, and the org-level concurrent run limit starts creating queuing during peak merge windows. Projects help, but teams usually add them retroactively after the sprawl problem is already embedded. Start with a project structure on day one.

Sentinel vs. OPA choice

Sentinel is more expressive for Terraform-specific policy patterns. OPA is portable: the same policies work in Kubernetes admission controllers, CI pipelines, and any other OPA-compatible tool. For teams already using OPA elsewhere, investing in Sentinel means your policy logic stays trapped in HCP Terraform. For teams starting fresh, Sentinel's Terraform-native syntax is faster to write and test. The choice matters because migrating between the two later is non-trivial.

State migration

If you're moving an existing Terraform project to HCP Terraform, the state migration step is where things go wrong. Use terraform state push carefully, verify the state file in HCP Terraform before running any plans, and keep a local backup. We've seen teams accidentally apply against stale state during migrations. The correct order: migrate state, verify state, then trigger your first plan.

covers state design, module reuse, and security patterns that apply whether you're on HCP Terraform or self-managing.

Where env zero fits

HCP Terraform covers the core use case well, but there are places where the product's constraints become friction. Here's what we hear most from teams that evaluate both:

Predictable pricing

HCP Terraform's resource-based billing is opaque until you measure it. Infrastructure environments grow over time, and resource counts move in one direction. A platform team that automates aggressively is also the team that gets a larger bill. env zero's pricing is flat monthly plans rather than per-resource, which means the cost of running more automation is decoupled from the infrastructure complexity underneath it.

Unlimited concurrency

HCP Terraform caps concurrent runs at the org level, which creates queuing during peak merge windows. env zero offers unlimited concurrent runs across all plans, so a hundred workspaces applying simultaneously doesn't create a bottleneck.

Multi-IaC support

HCP Terraform is built around Terraform. If your organization also runs Terragrunt configurations, Pulumi stacks, Kubernetes manifests, Helm charts, or CloudFormation templates, you're managing multiple separate automation platforms. env zero runs all of these in a single system, with consistent RBAC, policy enforcement, and audit logging across the board.

For the 38% of teams currently evaluating OpenTofu, env zero supports OpenTofu and Terraform natively in the same workspace configuration, so you can run both during a migration without committing to either.

VCS and network security

HCP Terraform's VCS integration requires your repository to be reachable from HashiCorp's infrastructure. Teams with internal VCS behind a firewall have to open network access or upgrade to a tier with self-hosted agents. env zero's self-hosted agents are available on Cloud Navigator and above, run inside your network, and pull from VCS without requiring any inbound exposure.

Cost enforcement, not just estimation

HCP Terraform includes cost estimation: it tells you what a Terraform change would cost before you apply it. That's useful. env zero goes further with real-time cost tracking, budget alerts that can block deployments when thresholds are exceeded, and TTL environments that automatically destroy idle development infrastructure. The difference is estimation vs. enforcement.

AI capabilities

env zero includes Cloud Analyst for natural language infrastructure queries and Code Optimizer for automated security analysis. Neither has an equivalent in HCP Terraform today.

If you're on HCP Terraform and the free tier change pushed you to evaluate alternatives, env zero's pricing page has a direct comparison. And if you're evaluating from scratch, the Terraform Cloud alternatives guide covers the decision criteria in detail.

covers how platform teams build self-service IaC workflows that scale without becoming bottlenecks.

Try it with env zero

HCP Terraform handles the basics well, but the free tier sunset has made "what should we actually be paying for this" a real question. The free trial lets you connect your existing VCS, import a workspace, and see env zero's cost tracking and unlimited concurrency running against your real infrastructure. No commitment required.

Start a free trial or book a demo.

References

FAQ

What is HCP Terraform?

HCP Terraform is HashiCorp's managed SaaS platform for running Terraform at scale. It was previously called Terraform Cloud and was rebranded in April 2024 as part of HashiCorp's broader HashiCorp Cloud Platform (HCP) product line. It provides remote execution, shared state management, team access controls, policy enforcement via Sentinel and OPA, a private module registry, and VCS integration. HashiCorp was acquired by IBM in February 2025.

Is Terraform Cloud gone?

No. Terraform Cloud was renamed to HCP Terraform in April 2024. The product and its functionality continue under the new name. All existing Terraform Cloud accounts were migrated to HCP Terraform without any required action from users. References to app.terraform.io in module sources and configuration files still work.

What happened to the Terraform Cloud free tier?

The legacy HCP Terraform free tier, which offered unlimited managed resources, was discontinued on March 31, 2026. It was replaced by an enhanced Free tier that supports up to 500 managed resources with unlimited users. Organizations on the legacy plan were automatically transitioned. If your total resource count across all workspaces exceeds 500, you will need to move to a paid tier.

Does HCP Terraform work with OpenTofu?

No. HCP Terraform is built for HashiCorp Terraform and runs the Terraform binary. OpenTofu is a separate fork with its own binary and release cadence. For teams running OpenTofu, you need a platform that explicitly supports it. env zero runs both Terraform and OpenTofu natively in the same workspace configuration, which means teams can run both during a migration period without switching platforms mid-stream.

What is the difference between HCP Terraform, Terraform Enterprise, and Terraform OSS?

Terraform OSS is the open-source command-line tool: no collaboration layer, state stored wherever you configure the backend. HCP Terraform is the SaaS platform built on top of Terraform OSS, adding shared state, team controls, policy enforcement, and remote execution managed by HashiCorp. Terraform Enterprise is the same platform as HCP Terraform but deployed in your own infrastructure, for organizations with air-gap, data residency, or compliance requirements that prevent using a SaaS backend.

Can I use HCP Terraform without VCS integration?

Yes. HCP Terraform supports three workflow types: VCS-driven (automatic plans and applies triggered by repository events), CLI-driven (running terraform plan and terraform apply locally, with execution happening remotely in HCP Terraform), and API-driven (triggering runs programmatically via the API). VCS integration is the most common starting point, but CLI-driven workflows are useful for teams with existing CI pipelines that aren't ready to hand off trigger control to HCP Terraform.

How does HCP Terraform pricing work?

HCP Terraform uses resource-based pricing called Resources Under Management (RUM). RUM counts the managed resources in your Terraform state files, calculated hourly at your peak count. The current paid tiers are Essentials ($0.10/resource/month), Standard ($0.47/resource/month), and Premium ($0.99/resource/month). The Free tier covers up to 500 managed resources with unlimited users. Terraform Enterprise is priced by contract. Full details and a cost estimator are on HashiCorp's pricing page.