Terraform Cloud and Terraform Enterprise
Running terraform apply from a developer's laptop works fine for a solo project, but it breaks down quickly as teams grow: state can be overwritten by concurrent runs, credentials get scattered across machines, and there is no consistent record of who ran what and why. Terraform Cloud (TFC) is HashiCorp's managed SaaS platform that solves this by centralizing state storage, executing runs remotely in a consistent environment, and layering collaboration features like run approvals, variable sets, and policy checks on top of core Terraform. Terraform Enterprise (TFE) is the same platform packaged as self-hosted software for organizations with data residency, air-gapped, or compliance requirements that rule out a SaaS offering.
Cricket analogy: Running terraform apply from a laptop is like one player unofficially updating the team's batting order on a scrap of paper — fine solo, but chaos once two selectors edit it at once; TFC is the official, centrally-managed team sheet everyone reads from.
Workspaces as the Unit of Isolation
In Terraform Cloud, a workspace is roughly analogous to a working directory plus a state file plus a set of variables, but it is a first-class managed object rather than a local folder. Each workspace is tied to a version control repository (or a CLI-driven / API-driven workflow), holds its own state history, and can be configured with its own Terraform version, environment variables, and run triggers. Teams typically create one workspace per environment per component — for example, networking-prod, networking-staging, app-prod — so that a change to one environment cannot accidentally affect another.
Cricket analogy: A TFC workspace is like a franchise's dedicated dossier for one format — T20 squad, ODI squad kept separately — each with its own history, playing conditions, and roster, so a change to the T20 side never accidentally touches the ODI lineup.
The Remote Run Workflow
When a workspace is connected to VCS, pushing a commit automatically triggers a remote plan inside TFC's run environment, not on the developer's machine. This guarantees every plan is produced with the same Terraform version, the same provider versions, and the same variable set, eliminating the classic 'works on my machine' drift. A human (or a policy check) reviews the plan output, and only after approval does TFC execute the apply, again remotely, streaming logs back to the UI.
Cricket analogy: A VCS-connected workspace auto-triggering a remote plan on push is like a franchise's analytics team automatically re-running match simulations the moment a new player is signed, always using the same simulation engine version, then a selector approves before the change goes live.
terraform {
cloud {
organization = "acme-corp"
workspaces {
name = "networking-prod"
}
}
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}Policy as Code with Sentinel and OPA
TFC/TFE let organizations enforce guardrails on every plan before it can be applied, using Sentinel (HashiCorp's policy language) or Open Policy Agent. A policy might block any plan that would create an S3 bucket without encryption enabled, or reject a plan that provisions an instance type outside an approved list. Policies run as a distinct stage between plan and apply, giving platform teams centralized control without having to review every pull request by hand.
Cricket analogy: Sentinel policies gating every plan are like the ICC's playing-condition checks that automatically flag an illegal bat thickness before a match starts, or reject a boundary rope set at an unapproved distance, without an umpire reviewing every single prep by hand.
Think of Terraform Cloud's run pipeline as an assembly line with quality gates: plan (build the proposal), policy check (inspect against rules), and apply (ship it) — each gate can halt the line before a defective change reaches production.
Migrating an existing local or S3-backed state file into Terraform Cloud is a one-way operation from the perspective of workflow: once a workspace is 'cloud-managed' and teams stop running apply locally, losing access to the TFC organization (e.g., expired trial, billing lapse) can strand your ability to make further changes. Always keep a documented export/backup path for state.
- Terraform Cloud is HashiCorp's managed SaaS; Terraform Enterprise is the self-hosted equivalent for compliance-sensitive orgs.
- Workspaces isolate state, variables, and run history per environment/component.
- VCS-connected workspaces trigger remote plans automatically on commit, ensuring consistent tooling versions.
- Applies require explicit approval by default, giving teams a human checkpoint before infrastructure changes.
- Sentinel and OPA enable policy-as-code guardrails enforced between plan and apply.
- TFC centralizes state storage and access control, removing the need for teams to manage their own S3/DynamoDB backend.
Practice what you learned
1. What is the primary difference between Terraform Cloud and Terraform Enterprise?
2. In Terraform Cloud, what does a workspace primarily encapsulate?
3. What triggers a remote plan in a VCS-connected TFC workspace?
4. What role does Sentinel play in the Terraform Cloud run pipeline?
5. Why do teams typically create separate TFC workspaces per environment (e.g., prod vs staging)?
Was this page helpful?
You May Also Like
Remote State Backends
Remote backends store Terraform's state file outside the local disk, enabling team collaboration, durability, and integration with locking mechanisms.
State Locking
State locking prevents two Terraform operations from writing to the same state file simultaneously, protecting against corruption and lost updates.
Plan Review and Policy as Code
Explore how teams review `terraform plan` output for correctness and safety, and how policy-as-code tools like Sentinel and OPA automatically enforce organizational rules on every plan.
Terraform in CI/CD Pipelines
Learn the standard stages, safety controls, and credential-handling patterns for running Terraform reliably inside a CI/CD pipeline, from plan-on-PR to gated apply-on-merge.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics