gotchabashterraformModerate

Terraform workspaces isolate state but are not a replacement for separate environments

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

workspacesenvironment isolationterraform workspacestate isolationdev staging prodworkspace select

Problem

Terraform workspaces allow multiple state files within a single backend configuration. Teams use them to manage dev/staging/prod but run into problems: workspaces share the same configuration directory, IAM permissions, and provider credentials, making true environment isolation difficult.

Solution

Use workspaces for lightweight isolation of similar environments (e.g., feature branches, ephemeral testing). Use separate root modules with separate backends for strong environment isolation (dev, staging, prod).

# Create and switch workspaces
terraform workspace new staging
terraform workspace select staging
terraform workspace list

# Reference workspace name in config
resource "aws_instance" "web" {
  tags = {
    Environment = terraform.workspace
  }
}

For per-environment sizing:

locals {
  instance_type = terraform.workspace == "prod" ? "m5.large" : "t3.micro"
}

Why

Workspaces only separate state, not configuration or credentials. A mistake with terraform workspace select in the wrong terminal can apply prod changes from a dev plan.

Gotchas

The default workspace is named default — its state key lacks a workspace prefix
Workspaces do not provide IAM isolation — use separate AWS accounts per environment for strong isolation
Workspace state keys in S3 are at env:/<workspace>/<key> for non-default workspaces
Terragrunt is a better solution than workspaces for managing multiple environments with DRY config

Context

Managing multiple deployment environments with Terraform

Revisions (0)

No revisions yet.