Workspaces

Let's think about it this way for a second

Modules (from the previous lesson) are about code reuse, while Workspaces are about state isolation — from the very same config folder, running `terraform workspace new dev` and `terraform workspace new prod` creates two workspaces, and Terraform stores their state files separately (`terraform.tfstate.d/dev/`, `terraform.tfstate.d/prod/`) — applying in the dev workspace won't touch a single resource in the prod workspace. You can reference the built-in `terraform.workspace` variable in your config yourself, and vary a value depending on the workspace.

Let's connect this to a real scenario

With the sequence `terraform workspace new staging` → `terraform workspace select staging` → `terraform apply`, you can run the staging environment separately from the default environment — you can also vary a value by workspace with an expression like `instance_type = terraform.workspace == "prod" ? "t3.large" : "t3.micro"`.

A workspace is a mechanism for storing state files separately per environment
terraform workspace new/select creates or switches a workspace
terraform.workspace lets you reference the active workspace's name from your config

Let's look at it together

bash

# Create and switch to a new workspace
terraform workspace new staging

# List all workspaces
terraform workspace list

# Switch back to default
terraform workspace select default

# See which workspace is currently active
terraform workspace show

You should see

$ terraform workspace list
  default
* staging
  production

5-minute try-it

Create a new workspace with `terraform workspace new dev`, then try applying the `local_file` resource (from the Basic chapter) — switch back to the `default` workspace and confirm the state is split.

A quick word of caution

All workspaces share the same backend config (state storage location) — access control can't be split at the workspace level, so every developer may still have access to the production workspace.