Workspaces & environments

The same config should build dev, staging, and prod — differing only in inputs (sizes, counts, domains). The dangerous anti-pattern is copy-pasting a config per environment, where they silently drift apart.

variable "environment" { type = string }

locals {
  sizing = {
    dev     = { count = 1, type = "t3.small" }
    staging = { count = 2, type = "t3.medium" }
    prod    = { count = 6, type = "t3.large" }
  }
  cfg = local.sizing[var.environment]
}

resource "aws_instance" "api" {
  count         = local.cfg.count
  instance_type = local.cfg.type
}

Workspaces vs. separate state

A workspace gives one config multiple independent state files (terraform workspace new prod). It's fine for lightweight cases, but for hard prod isolation many teams prefer separate state backends plus per-environment *.tfvars, so a fat-fingered command can't target the wrong environment.

terraform workspace select staging
terraform apply -var-file=staging.tfvars

Promotion is repetition with new inputs

Promoting dev to staging to prod means applying the same config with the next environment's variables. Because the config is identical, what reaches prod is exactly what you exercised in staging — only the inputs changed. Tools like Pulumi express the same idea in general-purpose languages (TypeScript, Go) instead of HCL, but the model — declarative resources, state, a dependency graph, environment-scoped inputs — is the same.