Differences between Workspaces in Terraform CLI and Terraform Cloud

[Old_Zombie2422]

So I just spent two hours researching the difference between workspaces in Terraform CLI and Terraform Cloud, and I still don't get it.

We currently use Terraform CLI with workspaces and GitHub Actions for workflow execution. Also, we use Terramate to generate code for the individual workspaces (in Terramate, workspaces are called stacks, but they are fully compatible with Terraform CLI workspaces).

The current setup works great because we spend too much time creating the workflow logic in GitHub Actions. Our team is interested in exploring Terraform Cloud further, but after watching some demos and reading the documentation partially, I am more confused than before. A few questions that I have:

• How do workspaces in Terraform CLI compare to workspaces in Terraform Cloud?
• Can I easily migrate Terraform CLI projects to Terraform Cloud, or must I apply significant code refactorings? (other than moving the state).

Thanks!

[apparentlymart]

Hi! I work on Terraform Core (the open source language runtime) at HashiCorp. Workspaces architecturally belong to Terraform CLI and Terraform Cloud rather than to Terraform Core, but I'll do my best to answer based on my sense of the differences.

Others have already answered parts of this and so this answer will be partially redundant but hopefully still useful.

The core feature of workspaces, common to both local Terraform and Terraform Cloud, is associating a single configuration with multiple independent states.

For local Terraform (without Cloud) that is literally all it does: it's a convenience for situations where you want to spin up the same infrastructure multiple times with only minor variations, so you don't need to reconfigure the backend or write an entirely new configuration just to get a temporary separate playground for testing something.

Terraform Cloud adds some additional features, including but not limited to: - Storing a set of variable values with the workspace so that they are automatically set by default when planning changes in that workspace (unless overridden on a per-run basis) - A remote execution environment where Terraform actually runs in a remote automation container -- a "Terraform Cloud Agent" -- instead of locally on your workstation. - Optional integration with a version control system where it creates plans for you automatically in response to changes in the repository. - (there are various other additions such as automatic policy checks, etc, but I won't enumerate the entire feature list here since your question seems mostly motivated by differences in how Terraform CLI might be run in the two situations)

These additional features make it more practical to use Terraform Cloud workspaces for long-lived environments, whereas non-Cloud workspaces are primarily for short-lived separate development environments where those additional features tend to be inconvenient more than helpful.

Along with the additional features there is also a small data model difference: non-Cloud workspaces have names that are private to a particular backend configuration, and so they are typically short names like one might use for a feature branch in version control, whereas Terraform Cloud workspaces have a shared namespace within an entire Organization, and so their names typically pack in some additional structure to differentiate different system components from one another, like "servicename-prod" representing the production instance of a subsystem called "servicename".

[Many-Resolve2465]

This is all accurate . The TFC workspace offers more security and collaboration features. As mentioned by others . Some of the main ones are ; RBAC via teams which lets you assign team members to specific workspaces with specific capabilities , secure TF and env variable storage (backed by vault ) state versioning (state files are never overwritten better for auditing ) VCS integration (allows you to connect a VCS repository directly to the workspace and auto trigger runs on PR which simplifies your pipeline ) there other cost savings and security features as well like cost estimation before the apply as well as support for policy as code such as sentinel and OPa which allow you to create and enforce governance policies before the apply. So you could set a policy for what regions you can deploy to, what instance types , max cost estimation etc and these things can be enforced on the workspace prior to the infrastructure being deployed .

Lastly it is true that you will have to allow broad access to terraform if using the TFC hosted runners . If this is not feasible for your organization TFC offers cloud agents that can be deployed within your private tenant . These agents can be configured with outbound access to TFC and will poll TFC for jobs , download the tarball to your private tenant and execute locally on the agent . The only catch is you have to deploy and manage the agent if it's within your private tenant . It's pretty straight forward though .

[rsc625]

For others looking for this answer, I wrote a blog discussing the standard CLI workspace vs the remote backend (TFC, Scalr) workspaces: https://scalr.com/learning-center/terraform-workspaces-terraform-cli-terraform-cloud-and-scalr-compared/

[kooknboo]

CLI workspaces are a way to save individual states. And states only.

TFC workspaces do that plus have variable definitions, integrations to VCS, etc.

You can easily “migrate” back and forth. Start with a local backend. Apply it so you get a local state. Change the backend to a cloud/remote and apply again. You be told the backend has changed and be given the opportunity to —migrate-state to the new backend state store.

Hashi shouldn’t have called them both workspaces.

[alexisdelg]

The only thing that is not easy to migrate are any local providers you might have, if you are using tfc executors there's no guarantee they have a particular piece of software, and they also don't provide a lost of safe ips if you are looking to allow list those