Suppose you need separate production and staging deployments. A workspace gives each deployment its own state: the record of resources Terraform manages. A backend determines where that state is stored. In the standard workspace model, both deployments can use the same configuration, plugins, and modules while retaining separate state. section 1.2 section 6.4.7
Terraform Cloud uses the same word for a different system. Its workspaces are independent of one another: switching between them on a cloud-block-based backend does not carry over the code or modules that standard workspaces share. Decide which kind of workspace you are using before relying on a workspace switch to create another deployment. section 6.4.7
For standard workspaces, the CLI provides the basic controls:
- Use terraform workspace list to see available workspaces, new to create one, select to switch, and delete to remove one. section 6.4.7
- Use terraform.workspace in a configuration when a plan needs the selected workspace’s name; it can inform count or for_each decisions. section 6.4.7
Testing a reusable module
A reusable module can be exercised from a separate root-level example folder. Put provider configuration and a region input variable in providers.tf, then call the module from main.tf using a relative source path. From that folder, run terraform init, review the plan, and apply it. The region variable lets different deployments use different provider values without changing the reusable module. section 3.8.4 section 1.4
If you want standard workspaces for local development while also using Terraform Cloud, develop against a local backend. With a cloud block, terraform workspace commands address Cloud workspaces instead of the standard shared-code workspace feature. section 6.4.7
