Skip to main content
Welcome back. In this lesson you’ll create and configure your first HCP Terraform (Terraform Cloud) workspace, connect your local Terraform CLI, and review key workspace settings such as variables, execution mode, Terraform version, and VCS connections.

Create a new workspace (step-by-step)

  1. In the HCP Terraform UI, open Workspaces on the left and click New → Workspace.
  2. Choose a Project (use the Default Project if you don’t have another).
  3. Select the CLI-driven workflow for this demo. This workflow lets you migrate and run existing Terraform locally first, and later switch to a VCS-driven workflow.
  4. Set the workspace name to hcp-demo, optionally add a description (for example, “demo workspace for this demo”), and click Create.
A screenshot of the Terraform Cloud web UI showing a "Create workspace" form with "Default Project" selected and the Description field filled with "demo workspace for the course." The left sidebar highlights "Workspaces" and the "Cancel" and "Create" buttons are visible at the bottom.

Workspace overview and initial state

  • After creation, the workspace header shows the workspace name and workspace ID — useful when scripting or integrating with APIs.
  • You can lock the workspace to prevent changes.
  • A new workspace will show zero resources until you connect a configuration and execute runs.
  • The workspace displays the Terraform version HCP Terraform will use; change it in settings if needed.
To authenticate your local Terraform CLI with HCP Terraform:

Use the Terraform cloud block to target the workspace

Add a terraform block to your local configuration to target the hcp-demo workspace. Example:
After adding this block, initialize and run your configuration:
This initializes the working directory to use the HCP Terraform workspace and starts a run that will reflect back into the workspace UI (plans, states, resources).

State and runs

  • The workspace will show “waiting for configuration” until you connect a local configuration or VCS repository and execute runs.
  • After the first successful apply, the workspace will record runs, states, tracked resources, and outputs.
A screenshot of the Terraform Cloud web UI showing the "hcp-demo" workspace States page. It displays that the workspace currently has no saved states, with navigation on the left and a "New run" button on the right.

Variables and sensitive values

Each workspace has a Variables section for Terraform and environment variables scoped to that workspace:
  • Use Terraform variables for configuration values consumed by your .tf files.
  • Use environment variables for provider credentials or other runtime secrets (for example: AWS_SECRET_ACCESS_KEY, AZURE_CLIENT_SECRET).
  • Mark values as Sensitive to ensure they are write-only in the UI.
Sensitive variables are write-only in the UI. You can view values while adding them, but after saving they cannot be read back from the UI for security reasons. Store a copy elsewhere if you need to reuse the secret.
To add a variable:
  1. Click Add Variable.
  2. Choose Variable or Environment Variable.
  3. Enter the key and value.
  4. Toggle Sensitive if necessary, then Save.
A screenshot of Terraform Cloud's "Edit variable" modal showing an environment variable with the key AWS_SECRET_ACCESS_KEY. The value field is marked "sensitive — write only" (Sensitive checkbox checked) and there are Save/Cancel buttons.

Execution mode and Terraform version

  • Execution mode is set per workspace; remote execution (runs executed by HCP Terraform) is common.
  • Enable Auto-apply to automatically apply plans after a successful plan run (use with caution).
  • Select a Terraform version that matches your local environment to avoid incompatibilities. Choose a version available in the dropdown (for example, Terraform 0.12 or any 1.x release).
A screenshot of a Terraform Cloud workspace settings page, showing the "Terraform Version" dropdown open with selectable versions and a search field. The left sidebar lists workspace settings like General, Locking, and Notifications while sharing options appear below the dropdown.
Remember to save workspace settings after changing the Terraform version or any other setting.

Policies, run tasks, and other settings

Workspace settings let you configure locking, notifications, Sentinel policies, run tasks, run triggers, SSH keys, and VCS connections. If you use policy-as-code, you can enable the new Sentinel policy experience at the workspace level.
A screenshot of the HashiCorp Terraform Cloud workspace "Policies" settings showing the "Sentinel Experience" section with a blue toggle enabled for "Enable the new Sentinel policy experience." The left sidebar lists workspace settings like General, Locking, Notifications, and Policies.

Version control (VCS) connections

  • You can connect a workspace to a VCS repository to trigger runs from commits or pull requests.
  • Until you connect a repository, the workspace will show Not Connected and provide a Connect to version control button.
A screenshot of the Terraform HCP workspace "Edit Version Control" settings page showing the workspace is "Not Connected" and a blue "Connect to version control" button. The left sidebar lists workspace settings like General, Locking, Notifications, and Version Control.
When connected, you can enable automatic plan/apply behavior for designated branches and use VCS for collaboration and audits.

Destroying infrastructure and deleting a workspace

To remove resources managed by the workspace, create and apply a destroy plan:
After destroying infrastructure you can remove the workspace from the UI.

Resources Under Management (RUM) licensing

HCP Terraform licensing is based on Resources Under Management (RUM). Free accounts typically allow up to 500 resources across workspaces. Monitor the Resources count per workspace to avoid exceeding plan limits.

Quick reference: common workspace settings

Wrap-up

You created the hcp-demo workspace, reviewed workspace settings (execution mode, Terraform version, variables, and policies), learned how to connect local Terraform via the cloud block, and saw how to destroy resources and delete the workspace. Next steps: migrate an existing local repo into this workspace (CLI-driven migration) and then switch to a VCS-driven workflow for automated runs. Further reading:

Watch Video