Terraform Cloud vs OpenTofu in 2026: Is HCP Terraform Still Worth It?

The infrastructure-as-code tooling market looks different in 2026 than it did three years ago. HashiCorp’s 2023 license change from MPL to BSL fractured the Terraform community, triggered the OpenTofu fork under the Linux Foundation, and forced every team running Terraform to make an explicit choice: stay on the commercial product, move to the fork, or reconsider the whole stack.

That’s the context for evaluating HCP Terraform (formerly Terraform Cloud) today. It’s not just “is the SaaS platform worth the money” — it’s “what does it give you that a self-hosted OpenTofu pipeline doesn’t, and does that gap justify the cost?”

What changed in 2023

HashiCorp announced the Business Source License switch in August 2023. Under BSL, Terraform is free to use but cannot be used to build a competing product without a commercial license from HashiCorp. The practical impact on most teams is zero — the BSL doesn’t affect internal use of Terraform for managing your own infrastructure.

The community reaction was sharp anyway. OpenTofu, backed by Gruntwork, Spacelift, Harness, and others, forked the last MPL-licensed version of Terraform (1.5.5) and submitted it to the Linux Foundation. OpenTofu 1.6 shipped in January 2024, and the project has moved faster than many expected, adding features like provider-defined functions and early encrypted state that Terraform hasn’t matched.

For teams evaluating HCP Terraform, the license question matters because it affects your leverage. If you’re locked into HCP Terraform, you’re locked into HashiCorp pricing and roadmap. OpenTofu gives you a credible exit path.

HCP Terraform free tier: what you actually get

HashiCorp retired the old user-seat-based free tier in 2024 and moved to resource-based pricing. The current free tier is limited:

• Up to 500 managed resources
• Single organization
• Remote execution and state storage
• Basic team management (two teams, five users)
• Private module registry
• VCS integration

For a small team managing a non-trivial AWS environment, 500 resources disappears fast. A standard three-tier application with VPC, subnets, security groups, RDS, ECS cluster, ALB, Route 53 records, and associated IAM policies will hit 150-200 resources without trying. Add a staging environment and you’re near the ceiling.

The free tier is genuinely useful for learning and for individual projects. For a team managing production infrastructure, it’s a trial, not a sustainable operating model.

HCP Terraform Plus pricing

The paid tier runs $20 per user per month (billed annually as of early 2026, though pricing has changed enough times to warrant checking the current page before budgeting). For a five-person platform team that’s $1,200/year.

What you get over the free tier:

• Unlimited resources
• Up to 20 concurrent runs
• Sentinel policy-as-code
• Cost estimation on plans
• Audit logging
• Single sign-on (SAML/OIDC)
• Run tasks integration
• Drift detection

The per-user cost looks reasonable until you factor in that “users” means anyone who needs access to the Terraform workspace UI — not just the engineers writing Terraform. If developers, security reviewers, and managers all need visibility into infrastructure changes, the seat count climbs.

The self-hosted alternative: OpenTofu + S3 + DynamoDB

The standard self-hosted setup pairs OpenTofu with an S3 backend for state storage and DynamoDB for state locking. This is the same pattern that worked with Terraform before HCP Terraform existed, and it’s still solid.

Backend configuration in your root module:

terraform {
  required_version = ">= 1.6"

  backend "s3" {
    bucket         = "my-org-tfstate"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    kms_key_id     = "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"
    dynamodb_table = "terraform-state-locks"
  }
}

The DynamoDB table for locking:

resource "aws_dynamodb_table" "tf_locks" {
  name         = "terraform-state-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  server_side_encryption {
    enabled = true
  }

  tags = {
    Purpose   = "terraform-state-locking"
    ManagedBy = "terraform"
  }
}

With OpenTofu replacing the terraform binary, the backend configuration is identical — the S3 backend is implemented in the provider layer which OpenTofu maintains:

# Install OpenTofu
brew install opentofu  # macOS
# or
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh

# Usage is a drop-in replacement
tofu init
tofu plan
tofu apply

The infrastructure cost for this setup is minimal. An S3 bucket with versioning enabled and a pay-per-request DynamoDB table for a typical team costs under $5/month. Compare that to $1,200+/year for HCP Terraform Plus.

What you’re giving up: the operations work to maintain CI/CD pipeline configuration, the UI for browsing runs and state, and the enterprise features listed above.

GitLab CI as the orchestrator

If you already have GitLab, you may not need HCP Terraform at all. GitLab has a built-in Terraform state backend (available on all tiers), and GitLab CI handles the execution model that HCP Terraform provides.

# .gitlab-ci.yml — complete OpenTofu pipeline

image: ghcr.io/opentofu/opentofu:latest

variables:
  TF_ROOT: ${CI_PROJECT_DIR}/infrastructure
  TF_STATE_NAME: production
  TF_HTTP_ADDRESS: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}"
  TF_HTTP_LOCK_ADDRESS: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock"
  TF_HTTP_UNLOCK_ADDRESS: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${TF_STATE_NAME}/lock"
  TF_HTTP_USERNAME: "gitlab-ci-token"
  TF_HTTP_PASSWORD: "${CI_JOB_TOKEN}"
  TF_HTTP_LOCK_METHOD: "POST"
  TF_HTTP_UNLOCK_METHOD: "DELETE"
  TF_HTTP_RETRY_WAIT_MIN: "5"

stages:
  - validate
  - plan
  - apply

.tofu-base:
  before_script:
    - cd ${TF_ROOT}
    - tofu init

validate:
  extends: .tofu-base
  stage: validate
  script:
    - tofu validate
    - tofu fmt -check -recursive
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

plan:
  extends: .tofu-base
  stage: plan
  script:
    - tofu plan -out=plan.tfplan
    - tofu show -json plan.tfplan > plan.json
  artifacts:
    paths:
      - ${TF_ROOT}/plan.tfplan
      - ${TF_ROOT}/plan.json
    expire_in: 1 week
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

apply:
  extends: .tofu-base
  stage: apply
  script:
    - tofu apply plan.tfplan
  dependencies:
    - plan
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  when: manual
  environment:
    name: production

This setup gives you plan output on merge requests, manual apply gates on the default branch, and state stored in GitLab’s built-in backend with locking. For the detailed walkthrough of this pipeline pattern, see GitLab CI + Terraform IaC Pipeline.

The missing pieces compared to HCP Terraform: you won’t have Sentinel policies (though you can approximate this with OPA and conftest in a validation stage), and the run history UI is the GitLab pipeline UI rather than a purpose-built Terraform interface. For most teams that’s a fair trade.

When HCP Terraform is worth it

Policy-as-code with Sentinel is the feature that genuinely has no direct open-source equivalent. Sentinel lets you write rules that block terraform apply if the plan violates policy — for example, no resources outside approved regions, no security groups with 0.0.0.0/0 ingress on port 22, or all S3 buckets must have encryption enabled. The rules run server-side before apply, and they work regardless of which machine or user triggered the run.

# Example Sentinel policy — enforce encryption on all S3 buckets
import "tfplan/v2" as tfplan

s3_buckets = filter tfplan.resource_changes as _, rc {
    rc.type is "aws_s3_bucket" and
    (rc.change.actions contains "create" or rc.change.actions contains "update")
}

require_encryption = rule {
    all s3_buckets as _, bucket {
        bucket.change.after.server_side_encryption_configuration is not null
    }
}

main = rule { require_encryption }

You can replicate this with OPA and conftest in a CI stage, but the integration is more fragile and easier to bypass. Sentinel in HCP Terraform is enforced at the platform level.

Drift detection is the other feature worth paying for in regulated environments. HCP Terraform can poll your actual AWS resources on a schedule and alert when they diverge from state. Rolling this yourself requires writing a scheduled job that runs tofu plan and parses the output, which is doable but not free to build and maintain.

Audit logging at the organization level — who ran which workspace, what plans were approved, which applies were triggered — is baked into HCP Terraform Plus. Reconstructing this from GitLab CI logs is possible but requires deliberate instrumentation.

When it’s not worth it

Small teams with an existing CI/CD platform don’t need HCP Terraform. If you have GitLab, GitHub Actions, or Jenkins, you already have the execution model. S3 + DynamoDB covers state storage and locking for effectively nothing. The only missing capability is Sentinel, and if your compliance requirements don’t mandate server-side policy enforcement, OPA + conftest in a pipeline stage is sufficient.

Cost-sensitive organizations should do the math before committing. Five engineers on HCP Terraform Plus is $1,200/year. Ten engineers is $2,400/year. That budget funds an engineer’s time to build and maintain a self-hosted pipeline — a one-time investment rather than a recurring cost that scales with headcount.

Teams that have already moved to OpenTofu have additional reason to stay self-hosted. HCP Terraform runs the commercial Terraform binary, not OpenTofu. If you’re using OpenTofu-specific features (provider-defined functions, encrypted state), you can’t use HCP Terraform for execution — the binaries are different products.

Decision framework

The inflection point for most teams is around compliance requirements. If you need demonstrable policy enforcement, audit trails that satisfy an external auditor, and drift detection with no additional engineering work, HCP Terraform is worth the cost. If you’re managing infrastructure for a company that doesn’t have those requirements, you’re paying for overhead you don’t need.

The license question adds weight to the self-hosted case. OpenTofu is governed by the Linux Foundation, its license is stable, and the community is active. For teams that want infrastructure tooling with long-term predictable licensing, OpenTofu + S3 backend + GitLab CI is the more defensible choice in 2026.

For the full comparison of Terraform and OpenTofu feature parity, see Terraform vs OpenTofu 2026. For the import workflow on either platform, see Terraform Import.