Skip to main content
This lesson demonstrates Terraform Cloud’s core concepts and workflow: organizations, workspaces, runs, state management, secrets, VCS integration, and the private module registry. Follow along to understand how teams centralize Terraform state, automate plans/applies, and reuse modules securely.

​
Organization dashboard and navigation

When you sign in to Terraform Cloud you select the organization to work with. The organization dashboard lists workspaces, shows run statuses, and exposes the primary navigation tabs (Workspaces, Registry, Settings). Your signed-in user appears in the top-right corner and organization-level settings are available from the sidebar.
A Terraform Cloud "Workspaces" dashboard listing multiple workspaces with their run status badges (e.g., Applied, Planned and finished, Errored), repository names, and latest change timestamps. The header shows the Enterprise‑Cloud account with navigation tabs (Workspaces, Registry, Settings).

​
Plans, billing, and feature highlights

Organization Settings → Plan & billing shows your subscription tier and enabled features. The Free tier supports up to five users and includes remote state storage, unlimited workspaces, VCS integration, notifications, remote applies, and a private module registry. Paid tiers add governance and enterprise controls.
A web settings page showing "Plans" and billing options for a cloud product, with the Free plan marked as current and paid Team and Team & Governance tiers listed (20 and 70 per user/month). The left sidebar shows organization settings like Plan & billing, Tags, Teams, Users, and security options.

​
Workspaces and runs

Drill into a workspace (for example, an application development workspace) to see its run history. The Runs view provides a consolidated log of plan and apply runs, including the trigger (VCS, API, or manual) and status. Terraform Cloud stores state securely and maintains a versioned history for auditability.
Screenshot of a Terraform Enterprise workspace "Runs" page showing the Current Run and a Run List. Each entry displays run titles, branch and commit IDs, and green "Applied" status badges.
Terraform Cloud keeps detailed state history and an audit trail so you can see who made changes, how runs were triggered, and the exact state contents.
A web dashboard for a Terraform/AWS workspace ("devops-aws-myapp-dev") showing the States tab with a list of recent state changes. Each entry lists actions like "Added security group module" or "Triggered via UI" with user avatars, run IDs/commit hashes and timestamps (24 days ago).
Here is a trimmed example of a Terraform state snapshot showing outputs stored in state:

​
Variables, secrets, and workspace locking

Workspaces centralize Terraform variables and environment variables (for example, cloud credentials), keeping secrets out of source code. Use the Variables tab to add variables, mark values as sensitive, and choose the visibility scope.
Store cloud credentials and secrets in workspace variables and mark them as sensitive. Sensitive variables are write-only in the UI and won’t be displayed in plan logs. Use workspace locking to prevent concurrent changes during investigations or releases.
A screenshot of the Terraform Cloud workspace "devops-aws-myapp-dev" on the Variables tab showing no workspace variables and an "Add variable" button. The header shows the workspace ID, Terraform version (1.0.7), and that the workspace is unlocked.
Example of how AWS credentials appear (values masked / write-only for secrets):
When a workspace is unlocked you can trigger runs directly from the UI (Plan and Apply, Plan only, Refresh state, etc.). You can also lock a workspace to pause changes while you investigate or prepare a release.
A modal dialog titled "Start a new run" from a Terraform/HashiCorp UI, showing a note about auto-apply and a field for the reason for starting the run. Below that is a dropdown to choose the run type with options like "Plan and apply (standard)," "Refresh state," and "Plan only."

​
Workspace general settings and preferences

Workspace General Settings let you configure a description, execution mode (Remote or Local), and apply behavior (Auto apply or Manual apply). Pin a workspace to a specific Terraform version if needed.
A screenshot of a "General Settings" page for a Terraform Cloud workspace. It shows the workspace ID and name (devops-aws-myapp-dev), a description ("My Clumsy Bird Application - AWS - Development"), and options for Execution Mode (Remote/Local) and Apply Method.
Additional workspace options include the Terraform working directory (when using monorepos), state sharing (share state with specific workspaces or all), and UI preferences (structured run output vs. console UI).
A web UI screenshot of Terraform workspace settings showing fields for the Terraform working directory, remote state sharing options (select specific workspaces or share with all), and user interface choices (Structured Run Output or Console UI). A "Save settings" button is visible at the bottom.

​
Notifications and VCS integration

Configure notifications to alert on workspace events (run succeeded, run failed, etc.) via email, Slack, Microsoft Teams, or webhooks. Triggers and filters let you fine-tune when notifications are sent. Terraform Cloud integrates with popular version control systems. Connect a repository to trigger runs on commits, branches, or tags. You control whether commits auto-apply or require manual approval and can restrict triggers to specific paths.
A screenshot of a Terraform Cloud workspace Settings page showing Version Control connected to a GitHub repository (guhaentz/clumsy_bird). The page also displays workspace settings such as the Terraform working directory and apply method.
A screenshot of a Terraform workspace settings page showing options for Apply Method (Auto apply or Manual apply), Run Triggers (Always trigger runs, only on path changes, or on git tag), and a VCS branch field set to "development." The lower part shows a "Pull Requests" section header.
For teams that prefer local workflows, a CLI-driven approach remains supported. Terraform Cloud also exposes a full API for automation. Version control-driven workflows are the most common for teams adopting Terraform Cloud.
A web app settings screen titled "Choose your workflow" showing options for Terraform workflows — "Version control workflow," "CLI-driven workflow," and "API-driven workflow" — with brief descriptions and "Learn More" links. The top navigation highlights the Settings tab.
When a commit triggers a run, Terraform Cloud shows the exact diff that caused the change. For example, a module source update might look like this:

​
Metrics, teams, and access controls

Workspaces expose metrics such as run frequency and average plan/apply duration. Tags and role-based access controls help teams organize workspaces and manage contributor permissions.
Screenshot of a workspace dashboard showing the latest run triggered via the UI (a destroy run), with resource change counts, plan/apply duration, and an "Applied" status. The right column shows workspace metrics and settings.
Team creation, visibility (public/secret), and API tokens are managed from the organization settings for fine-grained control.
A settings page from a cloud web app showing the "Team: owners" screen with visibility options (Visible or Secret), a section for creating a team API token, and a left-hand navigation menu (Teams, Users, API tokens, etc.). The top bar shows workspace/organization navigation.
Terraform Cloud integrates with common VCS providers including GitHub, GitLab, Bitbucket, and Azure DevOps.
A screenshot of HashiCorp Terraform Cloud's "Add VCS Provider" settings page, showing options to connect version control systems (GitHub, GitLab, Bitbucket, Azure DevOps) with a left-hand settings menu. The GitHub dropdown is open, showing choices like GitHub Enterprise and GitHub.com.

​
Private Module Registry

Terraform Cloud’s private registry lets organizations publish and share reusable modules privately. Browse modules, inspect version history, and copy usage snippets into your configurations.
A Terraform registry webpage listing AWS modules (s3-bucket, security-group, server, vpc) with Public/Private badges. A left filter panel shows providers (azurerm, aws) and a tooltip reads "Private: Only available in this private Terraform registry."
A typical module usage snippet looks like this:
To authenticate programmatically with the private registry, configure credentials in your Terraform CLI credentials file or CI environment:
The private registry provides module source code, version history, and documentation similar to the public Terraform Registry but scoped to your organization.

​
Workspace search and scaling practices

Use workspace filters and search to find workspaces by name, environment (development/production), status (running, errored), and other metadata. Centralizing state, runs, and modules in Terraform Cloud helps teams scale collaboration while maintaining auditability.
A screenshot of the HashiCorp Terraform Cloud "Workspaces" dashboard listing multiple workspaces, their run status (green "Applied" or "Planned and finished", and a red "Errored"), associated repositories, and the time of the latest change. The top shows filters and a "New workspace" button.

​
Upgrading and enterprise features

If your organization needs policy enforcement, cost estimation, or advanced RBAC, upgrading to a paid plan adds features such as Sentinel policy-as-code, run tasks, and broader access controls.
A settings page for an enterprise cloud app showing Plan & Billing. The main panel lists subscription tiers (Free, Team, Team & Governance) with features and pricing, while a navigation sidebar appears on the left.
Terraform Cloud’s UI and feature labels can change over time. The core concepts—workspaces, remote state, runs, variables, VCS integration, and the private registry—remain stable. Sign up for a Terraform Cloud account and follow the docs for the latest UI and APIs.

Watch Video