>_SecOpsLog_
BlogIaC

Terraform workspaces vs directories for environments

When workspaces help and when separate directories are safer for dev, staging, and prod — with the tradeoffs.

Mar 11, 2025·8 min readIntermediate

Terraform workspaces and separate directories both give you dev/staging/prod — but they trade off differently. Workspaces are quick and DRY; directories are explicit and safer for anything you can break. Choosing wrong is how a terraform apply meant for dev hits prod.

Two approaches
Workspaces
one config, N states
terraform workspace select
very DRY
easy to target the wrong one
Directories
envs/dev, envs/prod
separate backends
explicit + isolated
some duplication

Workspaces in practice

bash — same code, different statelive
terraform workspace new staging
terraform workspace select staging
Switched to workspace "staging".
terraform.workspace is now available in config
The prod footgun
Workspaces share one backend and one set of variables, and the active workspace is invisible in your files. For prod, a wrong `select` is a wrong apply. Most teams keep prod in its own directory with its own backend for exactly this reason.

When directories win

layout
live/
  dev/     { main.tf, backend.tf -> dev state }
  staging/ { main.tf, backend.tf -> staging state }
  prod/    { main.tf, backend.tf -> prod state }
modules/   { shared, versioned modules }

Use workspaces for ephemeral, low-risk variants (a per-developer sandbox); use directories for the environments you never want to confuse.

Go deeper in a courseTerraformState, workspaces, modules, and environment strategy.View course

Related posts

Terraform remote state and locking on S3 and DynamoDBMay 5, 2026 · 9 minScanning Terraform with Checkov before you applyFeb 12, 2026 · 8 minPolicy-as-code for Terraform: tfsec and OPA in reviewDec 16, 2025 · 10 min