No. Terraform CLI workspaces are named sets of state inside one backend, using the same credentials. HashiCorp's documentation says workspaces are not appropriate for deployments requiring separate credentials and access controls. If prod needs isolation from dev, separate the backends and the identities, not just the workspace name.
What a workspace is
Every Terraform configuration has one backend. Workspaces are named state files within it. You start in the default workspace, and terraform workspace new adds more. A plan in a new workspace does not touch resources in other workspaces, but those resources continue to exist.
This is handy for short-lived copies of the same configuration, such as a feature environment, where you can vary counts or tags using the workspace name.
Why it is not isolation
Everything below stays shared across workspaces:
- The backend. Anyone who can read or write the bucket can reach every workspace state, usually by changing a path.
- The credentials. The documentation says you can deploy multiple instances without changing authentication credentials. That is convenient, and it means a mistake or a compromise in one workspace carries the same permissions into the others.
- The code. The same configuration produces every environment, so a bad merge affects them together.
A typo in terraform workspace select can also point a destroy at production. Humans make that class of mistake regularly.
Patterns that do isolate
| Need | Approach |
|---|---|
| Different people or pipelines for prod | Separate backend, separate role, separate pipeline |
| Blast radius | Separate cloud accounts or subscriptions per environment |
| Config divergence | A directory or module call per environment, same modules |
| Short-lived copies | Workspaces are fine, within one trust level |
The key rule: the identity running prod applies should not be able to read or modify dev state, and the reverse. Different cloud accounts with their own deploy roles do this well.
A middle path
Many teams use one module and one root directory per environment. Each root has its own backend configuration and its own deploy role. Changes to the shared module are promoted by bumping a pinned version, which gives a natural promotion gate.
What to check in review
- Does the pipeline for production use a role that dev pipelines cannot assume?
- Is the production backend readable only by that role and a small set of humans?
- Are workspace names used for anything security relevant, like selecting an account? If so, treat that as a smell.
- Can a destroy run against production from a developer laptop?
Safeguard's policies and gates can hold pull requests to rules about protected environments, while asset discovery helps you see what actually exists in each account.
Quick check
Can I use workspaces for dev, staging and prod if each has its own tags?
You can, but it gives no access control separation. Tags do not change who can read state or deploy. Use separate backends and roles for anything that needs isolation.
Are HCP Terraform workspaces the same thing?
No. HashiCorp notes that CLI workspaces are different from HCP Terraform workspaces, which have their own access controls.
Sources
Last reviewed: 19 October 2026.
