What is Terraform Cloud/Enterprise, and what problems does it solve over open-source Terraform?

Terraform Cloud (now branded HCP Terraform) and Terraform Enterprise (the self-hosted version) are HashiCorp's managed platforms built around the same open-source Terraform engine, adding a layer of collaboration, governance, and execution infrastructure that teams would otherwise have to assemble themselves.

What open-source Terraform alone requires you to build

A typical DIY setup: an S3 bucket + DynamoDB table for remote state and locking, a CI pipeline (GitHub Actions/GitLab CI) to run plan/apply, a way to review plan output before merge, some ad-hoc convention for module versioning, and manually-managed IAM roles for who can trigger applies against which environment.

Pointing a configuration at Terraform Cloud

Instead of an s3/azurerm/gcs backend block, a configuration opts into the platform with a cloud block:

terraform {
  cloud {
    organization = "my-org"

    workspaces {
      name = "prod-network"
    }
  }
}

From here, terraform login authenticates the CLI, and terraform plan/apply execute as remote runs on Terraform Cloud's infrastructure rather than locally — the CLI just streams the log back to your terminal.

What Terraform Cloud/Enterprise adds out of the box

• Remote state storage with locking — no S3/DynamoDB setup needed; state lives in the platform, versioned and locked automatically.
• Remote/consistent execution — runs (plan/apply) execute on HashiCorp-managed (or self-hosted, for Enterprise) infrastructure rather than an individual's laptop or a bespoke CI runner, so environment/tooling drift between "my machine" and "the pipeline" disappears.
• Private module and provider registry — teams publish internal modules with proper versioning and discoverability, rather than relying on ad-hoc Git refs scattered across configs.
• Policy as code — Sentinel or OPA policies can block an apply that violates organizational rules (e.g., "no security group may allow 0.0.0.0/0 on port 22") before it ever executes, enforced centrally rather than hoping every reviewer catches it.
• Run history and audit logs — a searchable record of every plan/apply, who triggered it, and what changed, which is otherwise scattered across CI logs and ad-hoc conventions.
• Team/workspace-level RBAC — fine-grained control over who can plan vs. apply vs. manage variables for a given workspace, tied into SSO.

A minimal Sentinel policy blocking public ingress, enforced automatically before any apply that violates it is allowed to proceed:

import "tfplan/v2" as tfplan

no_open_ingress = rule {
  all tfplan.resource_changes as _, rc {
    rc.type is not "aws_security_group_rule" or
    rc.change.after.cidr_blocks is not ["0.0.0.0/0"]
  }
}

main = rule { no_open_ingress }

When teams reach for it

Once a Terraform footprint grows past a handful of engineers and a couple of environments, the DIY combination of S3+DynamoDB+CI+ad-hoc policy checks becomes its own maintenance burden. Terraform Cloud/Enterprise replaces that patchwork with a single, opinionated, governed platform — the tradeoff being cost (for Cloud's paid tiers or Enterprise licensing) and some loss of flexibility versus a fully custom-built pipeline.