HCP Terraform and Remote Collaboration

A remote backend solves an important problem: shared state. CI/CD solves another: repeatable execution. But once a team wants centralized runs, permissions, state, variables, VCS integration, and collaboration around those runs, it is useful to have a platform that brings those pieces together.

That is the role HCP Terraform.

What Is HCP Terraform?

HCP Terraform is HashiCorp’s managed platform for collaborative Terraform workflows.

Terraform itself is still the infrastructure-as-code engine.

HCP Terraform adds an operational platform around it.

A useful distinction is:

Terraform
    │
    └── infrastructure-as-code engine

HCP Terraform
    │
    ├── state
    ├── runs
    ├── workspaces
    ├── variables
    ├── permissions
    ├── VCS integration
    └── collaboration

HCP Terraform workspaces represent managed collections of infrastructure and can store state, variables, runs, and access-control settings. Remote execution can run Terraform on HCP Terraform’s disposable infrastructure.

HCP Terraform is therefore not a replacement for the Terraform language or CLI.

It is a managed way to operate Terraform.

Terraform CLI Versus HCP Terraform

With the CLI alone, you might have:

Developer laptop
      │
      ▼
Terraform CLI
      │
      ▼
S3 backend
      │
      ▼
Infrastructure

With HCP Terraform:

Developer / Git
      │
      ▼
HCP Terraform
      │
      ├── State
      ├── Runs
      ├── Variables
      ├── Permissions
      └── Terraform execution
              │
              ▼
        Infrastructure

The important change is where the operational control lives.

Instead of each engineer deciding how to execute Terraform, HCP Terraform provides a centralized system for managing runs and access.

HCP Terraform Workspaces

Do not confuse HCP Terraform workspaces with Terraform CLI workspaces.

A CLI workspace isolates multiple state files within one local Terraform working directory.

An HCP Terraform workspace is a managed infrastructure collection.

HashiCorp describes HCP Terraform workspaces as required for managing infrastructure in HCP Terraform. They also form a major part of the service’s permissions model.

A conceptual example:

HCP Terraform Organization
│
├── development-network
├── staging-network
├── production-network
├── development-application
└── production-application

Each workspace has its own state.

Remote State

Each HCP Terraform workspace has separate state data.

In remote execution mode, HCP Terraform automatically configures Terraform to use the workspace’s state, so you do not need to configure a traditional backend in the same way you would for S3.

This gives you:

Workspace
   │
   ├── Configuration
   ├── Variables
   ├── State
   ├── Runs
   └── Permissions

That grouping is one of the major reasons HCP Terraform can simplify team operations.

Remote Execution

With local Terraform:

Your laptop
   │
   ├── Terraform binary
   ├── provider plugins
   ├── credentials
   └── execution

With remote execution:

Your laptop / Git
       │
       ▼
HCP Terraform
       │
       ▼
Disposable execution environment
       │
       ▼
Cloud provider

For workspaces using remote execution, HCP Terraform performs Terraform runs on its own disposable virtual machines. That provides a consistent execution environment. It also means the laptop is no longer the machine that actually performs the production apply.

The Collaboration Workflow

A common workflow looks like:

Git Repository
      │
      ▼
HCP Terraform
      │
 ┌────┴────┐
 ▼         ▼
Plan      State
 │
 ▼
Review
 │
 ▼
Approval
 │
 ▼
Apply
 │
 ▼
Infrastructure

This changes the experience for the team.

A developer can create a pull request.

HCP Terraform can create a run associated with the change.

The team can inspect the plan.

An authorized person can approve the run.

The apply happens in the controlled execution environment.

The state remains associated with the workspace.

VCS Integration

HCP Terraform workspaces can connect to version-control repositories containing Terraform configuration.

Conceptually:

Developer
    │
    ▼
Git Push
    │
    ▼
VCS Repository
    │
    ▼
HCP Terraform Workspace
    │
    ▼
Terraform Plan

This means the Git repository remains the source of Terraform configuration while HCP Terraform becomes the execution and collaboration layer.

That is an important separation.

Git
 │
 └── "What code should run?"

HCP Terraform
 │
 └── "How and by whom should it run?"

State
 │
 └── "What does Terraform currently manage?"

Variables and Variable Sets

Terraform needs variables.

In a local workflow, you might use:

terraform.tfvars
TF_VAR_...

In HCP Terraform, variables can be associated with workspaces and organizations can use variable sets to share common variables across multiple workspaces.

This is particularly useful when several workspaces share configuration such as:

AWS region
Common tags
Organization-specific settings
Provider authentication inputs

Variable sets reduce repetition.

But shared variables should not become a dumping ground.

The same least-privilege principle applies to secrets and credentials.

Permissions and Teams

A production Terraform system needs more than “everyone can apply.”

HCP Terraform provides teams and workspace-level access controls.

Teams can be given different levels of access to workspaces, including roles such as:

Read
Plan
Write
Admin

and more granular permissions are available.

A conceptual organizational model might be:

Platform Team
   │
   ├── Admin production networking
   └── Admin shared infrastructure

Application Team
   │
   ├── Plan production application
   └── Write development application

Developers
   │
   └── Read production

The exact permissions should match your organization.

The principle is:

Permissions should follow responsibility.

Projects and Workspace Organization

As an organization grows, you may have many workspaces.

HCP Terraform provides projects for grouping workspaces and scoping permissions.

For example:

Projects
│
├── Platform
│   ├── production-network
│   └── shared-services
│
├── Payments
│   ├── production
│   └── staging
│
└── Internal Tools
    ├── production
    └── development

This can make ownership and access boundaries easier to reason about.

Run History

A manually executed Terraform command leaves much of the operational context on the machine that ran it.

A centralized service can provide a history of runs:

Run 104
  │
  ├── configuration version
  ├── plan
  ├── approval
  ├── apply
  └── result

Run 105
  │
  └── ...

This helps answer questions such as:

• What changed?
• Which run applied it?
• When did it happen?
• What was the plan?
• Who approved the operation?
• Did it succeed?

Auditability is one of the biggest benefits of centralized Terraform operations.

Private Module Registry

Teams often build reusable Terraform modules.

Earlier in the course, you learned that modules can come from different sources.

HCP Terraform also provides a private module registry for organizations.

That gives a team a controlled place to publish and consume reusable internal modules.

Conceptually:

Platform Team
     │
     ▼
Private Module Registry
     │
 ┌───┴────┐
 ▼        ▼
App A    App B

This can help standardize infrastructure patterns without forcing every team to copy module source into its own repository.

Remote State Sharing

Sometimes one Terraform configuration needs information managed by another.

HCP Terraform supports controlled state sharing between workspaces. Its configuration can restrict which workspaces are allowed to access another workspace’s state.

That creates a useful boundary:

Network Workspace
       │
       │ selected outputs
       ▼
Application Workspace

Rather than giving every workspace unrestricted access to every other workspace’s state, access can be deliberately scoped.

Remember that state can contain sensitive information.

State sharing is therefore an access-control decision, not just a convenience feature.

Remote Versus Local Execution

HCP Terraform supports different execution modes.

The important conceptual distinction is:

Remote

HCP Terraform performs the Terraform operations.

HCP Terraform
      │
      └── Terraform run

Local

Your machine performs the Terraform operations while HCP Terraform can still provide state storage and related services.

Agent

An HCP Terraform agent can execute runs in infrastructure you control, which is useful when Terraform needs access to private networks or isolated infrastructure.

Current HCP Terraform documentation identifies Remote, Local, and Agent execution modes.

The choice depends on where Terraform needs to run and what network or operational constraints exist.

HCP Terraform Does Not Remove Terraform Concepts

It is easy to think:

“If I use HCP Terraform, I don’t need to understand state, plans, providers, or Terraform CLI behavior.”

That is backwards.

HCP Terraform makes those concepts more operationally manageable.

You still need to understand:

• Terraform configuration
• State
• Providers
• Resources
• Modules
• Plans
• Applies
• Dependencies
• Authentication
• Permissions

The platform does not remove Terraform’s execution model.

It organizes it.

HCP Terraform Versus S3 + CI

You do not automatically need HCP Terraform.

A team can build a strong workflow with:

Git
 +
CI/CD
 +
S3 backend
 +
S3 locking
 +
IAM

That can be a perfectly reasonable architecture.

HCP Terraform becomes attractive when you want more of the collaboration layer managed for you:

S3 + CI
   │
   ├── You assemble the pieces
   ├── You maintain CI workflows
   ├── You manage state infrastructure
   └── You build approval conventions

HCP Terraform
   │
   ├── Managed state
   ├── Managed runs
   ├── Workspace permissions
   ├── VCS integration
   ├── Variable management
   └── Collaboration UI

The trade-off is that you are adopting a managed platform and its operational model.

A Complete Mental Model for Team Terraform

At the end of this section, think of the entire system as several cooperating layers:

                    Git
                     │
              Terraform Code
                     │
                     ▼
              Execution System
             ┌───────┴────────┐
             │                │
          CI/CD         HCP Terraform
             │                │
             └───────┬────────┘
                     ▼
               Terraform Run
                     │
                     ▼
              Remote State
                     │
              ┌──────┴──────┐
              ▼             ▼
           Locking       Access Control
              │             │
              └──────┬──────┘
                     ▼
              Cloud Provider
                     │
                     ▼
              Infrastructure

Each layer solves a different problem.

Git manages configuration history.

Terraform describes and changes infrastructure.

The backend or HCP Terraform manages state.

Locking coordinates concurrent writers.

CI/CD or HCP Terraform controls execution.

IAM and platform permissions control who can perform operations.

The cloud provider hosts the actual infrastructure.

The Core Lesson of Team Terraform

Terraform changes character when the only person running it is no longer you.

A local workflow can look like:

Edit
  │
  ▼
terraform apply
  │
  ▼
Infrastructure

A team workflow looks more like:

Configuration
     │
     ▼
Git
     │
     ▼
Review
     │
     ▼
Plan
     │
     ▼
Approval
     │
     ▼
Controlled Apply
     │
     ▼
Shared State
     │
     ▼
Infrastructure

The additional machinery is not bureaucracy for its own sake.

It exists because infrastructure has become shared.

A shared state file needs protection.

A production change needs coordination.

A cloud credential needs controlled access.

A plan needs review.

An apply needs an accountable execution path.

That is the central idea behind team Terraform.

Section 4 Complete

You started this section with Terraform running on a laptop:

Terraform on my laptop

You can now reason about the complete team-oriented model:

                  Git
                   │
             Configuration
                   │
                   ▼
          Terraform Execution
                   │
          ┌────────┴────────┐
          ▼                 ▼
       Plan/Review       Credentials
          │                 │
          └────────┬────────┘
                   ▼
             Remote Backend
                   │
             ┌─────┴─────┐
             ▼           ▼
          State        Locking
             │
             ▼
      Cloud Infrastructure

And, when a managed collaboration platform is appropriate:

Git
 │
 ▼
HCP Terraform
 │
 ├── Workspaces
 ├── State
 ├── Runs
 ├── Variables
 ├── Permissions
 └── Remote Execution
 │
 ▼
Infrastructure

Terraform itself did not become a different language.

The surrounding operational system became more disciplined.

That is what makes Terraform suitable for teams: not merely reusable configuration, but controlled state, coordinated changes, protected credentials, reviewable plans, and accountable execution.