HCP Terraform & Automation Platforms

The CI/CD pipeline in Best Practices — plan on PR, apply on merge, OIDC credentials, plan output in the PR — is something you assemble yourself from GitHub Actions. A Terraform automation platform gives you that pipeline as a product, plus managed state, a run UI, policy enforcement, and a private registry. HCP Terraform is HashiCorp's; several alternatives compete with it.

HCP Terraform (formerly Terraform Cloud)

HCP Terraform is HashiCorp's managed service. It has a generous free tier and paid tiers (Standard / Plus); Terraform Enterprise is the same product self-hosted in your own environment.

Organizations, Projects, Workspaces

Organization (my-company)
├── Project: networking
│   ├── Workspace: prod-network
│   └── Workspace: staging-network
└── Project: applications
    ├── Workspace: prod-app
    └── Workspace: staging-app

Connecting With the cloud Block

Instead of a backend block, point your config at HCP Terraform with a cloud block:

terraform {
  cloud {
    organization = "my-company"

    workspaces {
      name = "prod-network"
      # or select many by tag:
      # tags = ["networking", "production"]
    }
  }
}

Run terraform login once to authenticate, then terraform init. State now lives in HCP — encrypted, versioned, and locked automatically.

The Three Workflows

The Run Pipeline

A remote run moves through stages — each a place to gate or integrate:

plan  →  cost estimation  →  policy check  →  apply (auto or manual approval)
              │                   │
          Infracost-style     Sentinel / OPA
          $ delta in the UI   advisory or blocking

• Speculative plans run on PRs without the ability to apply — reviewers see the diff inline.
• Apply can require manual confirmation, or auto-apply on merge.
• Run triggers chain workspaces: an apply in prod-network kicks a run in prod-app that depends on its outputs.

Variables and Variable Sets

Workspace variables come in two kinds: Terraform variables (var.*) and environment variables (e.g., AWS_REGION, or provider auth). Both can be marked sensitive. Variable sets share a group of variables across many workspaces — define cloud credentials or org-wide tags once.

Private Registry

HCP Terraform hosts a private module registry and private provider registry for your organization — publish internal modules with semantic versioning, consume them with the same source/version syntax as the public registry:

module "vpc" {
  source  = "app.terraform.io/my-company/vpc/aws"
  version = "~> 2.0"
}

Policy as Code: Sentinel and OPA

Attach policy sets to workspaces. Policies run after plan and enforce at three levels:

# A Sentinel policy: forbid instances larger than xlarge
import "tfplan/v2" as tfplan

main = rule {
  all tfplan.resource_changes as _, rc {
    rc.type is not "aws_instance" or
    rc.change.after.instance_type not matches "(2|4|8|12|16|24)xlarge"
  }
}

HCP Terraform also runs OPA/Rego policy sets if you prefer Rego over Sentinel.

Run Tasks

Run tasks call out to third-party services at points in the run lifecycle (pre-plan, post-plan, pre-apply) — Infracost for cost, Snyk/Aqua for security, your own webhook for a custom gate. The external service returns pass/fail and a message shown in the run.

Drift Detection and Health Assessments

On paid tiers, HCP can run scheduled health assessments: drift detection (does real infrastructure still match state?) and continuous validation (do your check blocks still pass?), alerting when reality diverges — no cron job to maintain.

When to Use Something Else

HCP Terraform isn't the only option. The main alternatives:

Rules of thumb:

• Want zero infra to manage and you're all-in on HashiCorp? HCP Terraform.
• Want free and don't mind operating it? Atlantis — the pipeline lives in PR comments, state stays in your own S3 backend.
• Multi-tool estate (Terraform + Pulumi + Ansible) or need rich stack dependencies and drift? Spacelift.
• Already have your own CI you're happy with? You may not need a platform at all — the Best Practices GitHub Actions pipeline plus a remote backend covers a lot.

What's Next

Runs will eventually fail in ways the happy path doesn't cover. Next: upgrading versions safely and decoding the errors you'll actually hit → Upgrades & Troubleshooting.