HCP Terraform

HCP Terraform — formerly Terraform Cloud — is HashiCorp's managed service for running Terraform: remote state, remote runs with a built-in approval UI, a private module registry, policy enforcement, and team controls. It is the buy option for everything the last three topics had you build. Instead of standing up an S3 backend and writing a CI pipeline, you connect a repository and get plans on pull requests and applies on merge out of the box.

That convenience comes with a dependency and a pricing model — per-user or per-run, depending on tier. The honest question is not whether HCP Terraform works (it does) but whether buying the run platform saves more than building it costs you, which depends entirely on how much your team's time is worth against how much control you want.

What HCP Terraform Provides

Five things, roughly: managed remote state with locking (no S3 backend to bootstrap), remote runs that execute plan and apply on HashiCorp's infrastructure, a run approval UI where a human gates the apply, a private module registry for sharing modules across the organization, and policy enforcement through Sentinel (or OPA) to block plans that violate rules. Each of those is something you would otherwise assemble from S3, CI, and a pile of glue.

Workspaces in HCP

HCP Terraform uses the word "workspace" for something different from a CLI workspace, and the overlap trips people up constantly. A CLI workspace is multiple state files under one configuration — dev, prod as named states. An HCP workspace is a managed environment that pairs one state with its run history, variables, and settings — closer to "a directory with its own backend and pipeline" than to a CLI workspace. Same word, genuinely different concept; say which one you mean.

VCS-Driven Runs

Connect a repository to an HCP workspace and the plan-on-PR, apply-on-merge flow happens without you writing a pipeline. A pull request triggers a remote plan whose output appears both in HCP and on the PR; merging to the tracked branch queues an apply, gated by the workspace's approval setting. The configuration that points the CLI at HCP is a small cloud block in the terraform settings.

terraform {
  cloud {
    organization = "acme"
    workspaces {
      name = "network-prod"
    }
  }
}

This cloud block replaces the backend "s3" block — state lives in HCP, runs execute remotely, and the named workspace ties this configuration to its managed environment. There is no bucket, no lock table, and no pipeline YAML to maintain.

Policy and Governance

Sentinel and OPA let you enforce rules on every run as managed features — block a plan that creates an unencrypted bucket, forbid instance types above a size, require a tag. Combined with team permissions that scope who can apply to which workspace and an audit log of every run, this is the governance layer that is laborious to build yourself on raw CI. If policy enforcement is a hard requirement, it is one of the strongest reasons to buy rather than build.

Build vs Buy

The decision is HCP Terraform against a self-built S3 backend plus GitHub Actions. Buy when the managed state, approval UI, private registry, and policy save more engineer-time than the subscription costs, and when an external dependency is acceptable. Build when you want full control of the pipeline and credentials and the team can operate it. A two-person project rarely needs HCP; a regulated organization that would otherwise spend months reinventing Sentinel often does.