- Discovery becomes harder: lists with dozens or hundreds of workspaces slow down finding the right one.
- Repetitive changes are error-prone: updating variables or permissions per-workspace doesn’t scale.
- Team boundaries blur: everyone sees the same global list with no natural separation.
- Duplication and inconsistency: teams recreate identical variable configurations (for example, provider credentials) across many workspaces.

| Level | Purpose | What it contains / controls |
|---|---|---|
| Workspace (bottom) | Unit of deployment and runs | Terraform configuration, state, variables, and run history |
| Project (middle) | Grouping layer for related workspaces | Scoped team permissions, project-level variable sets, and execution-mode defaults |
| Organization (top) | Top-level account | Teams, projects, organization-wide defaults, and global permissions |

- Every workspace belongs to exactly one project.
- Workspaces cannot be in multiple projects or outside a project; each workspace is assigned to one and only one project.
- A default project is created for every organization.
- HCP Terraform creates a default project on organization creation. You may rename it, but you cannot delete it.
The default project guarantees every workspace has a project. Rename it to match your naming conventions, but note it cannot be removed. - Scoped team permissions:
- Grant teams access at the project level instead of on each workspace. Any current or future workspace added to that project inherits the project-level permissions automatically.
- Project-level variable sets:
- Attach variable sets (or organization variable sets) to the project so they apply to current and future workspaces in that project. This reduces duplication and enforces consistency.
- Execution mode inheritance:
- The organization defines an execution-mode default (remote, local, or agent). Projects can adopt sensible defaults for their workspaces, while individual workspaces retain the ability to override execution mode when needed.
- Moving workspaces:
- Move workspaces between projects to reflect team reorganizations or shifting responsibilities without re-creating the workspace.
- Infrastructure-as-code for project assignments:
- Manage workspace ↔ project relationships programmatically using the Terraform Cloud API or the Terraform
tfeprovider. Consult the provider/API docs for exact fields and examples: - Terraform Cloud API: https://www.terraform.io/cloud-docs/api-docs
tfeprovider docs: https://registry.terraform.io/providers/hashicorp/tfe/latest/docs
- Manage workspace ↔ project relationships programmatically using the Terraform Cloud API or the Terraform
- Deleting projects:
- A project must be empty before it can be deleted. Move or delete workspaces in a project prior to removing the project to avoid accidental orphaning of workspaces.
Only empty projects can be deleted. Always reassign or remove workspaces before attempting to delete a project.

| Benefit | How projects help |
|---|---|
| Faster discovery | Teams look in their project first instead of scanning a flat workspace list |
| Consistent configuration | Apply variable sets and execution defaults at the project level |
| Simpler permissions | Grant access to a whole project instead of individual workspaces |
| Reduced duplication | Shared variable sets and defaults eliminate repeated setup work |
| Scalable administration | Centralized changes propagate to current and future workspaces in the project |
- Create a new project,
- Assign existing workspaces to a project,
- Move workspaces between projects, and
- Attach project-level variable sets.
- Terraform Cloud API: https://www.terraform.io/cloud-docs/api-docs
tfeprovider (Terraform Cloud provider): https://registry.terraform.io/providers/hashicorp/tfe/latest/docs- Terraform Cloud documentation: https://www.terraform.io/cloud-docs