DRY Configuration Patterns

The standing objection to directory-per-environment is duplication. If envs/hatch-app-prod/ and envs/hatch-app-staging/ are separate directories, won't they drift apart the moment someone fixes one and forgets the other? It is a fair worry, and the answer is that native Terraform already has the tools to keep environment directories thin and identical in structure, differing only in values — no wrapper tool required.

Three patterns do the work: shared child modules so the logic lives once, per-environment .tfvars so only values differ, and partial backend config so the backend block is one template. Together they make a directory split DRY without giving up the physical isolation the previous topic argued for. This topic also marks the ceiling — the point where chasing DRY makes the code worse, not better.

Shared Child Modules

The real logic lives once, in modules/service-project or modules/ingest-pipeline. Each environment directory is a short module call into it. Changing the module changes every environment on the next apply, and there is nothing to copy, because the directories never held the logic in the first place — only the call to it. This is the same modules/ + envs/ split from Topic 64, now seen as the primary DRY mechanism.

The discipline is that no resource block belongs in an envs/ directory. The moment a real resource appears there instead of a module call, it is a candidate to drift, because its twin in the other environment is a separate copy. Push it into the module and the surface where two environments can diverge shrinks to the variables you pass in.

Per-Environment .tfvars

The only thing that genuinely differs between prod and staging is values — a machine size, a replica count, a project ID. Keep those in prod.tfvars and staging.tfvars and pass them with -var-file. The .tf files stay structurally identical across environments; the difference between prod and staging is one file of values, which reads as a diff and reviews as a diff.

# envs/hatch-app-prod/prod.tfvars
project_id     = "hatch-app-prod"
min_instances  = 3
db_tier        = "db-custom-4-16384"

# envs/hatch-app-staging/staging.tfvars
project_id     = "hatch-app-staging"
min_instances  = 0
db_tier        = "db-f1-micro"

Both directories run the same main.tf calling the same module; the apply differs only by -var-file. You can read the entire production-versus-staging difference in those few lines, instead of diffing two full configurations to find what changed.

Partial Backend Config

The backend block can omit the per-environment prefix and supply it at init time. Leave the gcs backend with only the bucket, then run terraform init -backend-config="prefix=apps/hatch-app-prod". One backend template serves every stack, with one state key per environment, and there are no duplicated backend blocks where someone can paste prod's prefix into staging's directory.

# backend.tf — identical in every env directory
terraform {
  backend "gcs" {
    bucket = "hatch-tfstate"
    # prefix intentionally omitted — supplied at init
  }
}

The init command carries the only per-environment fact the backend needs. Because the prefix is passed in rather than written in each directory, the backend block is genuinely the same file everywhere, and the surface where someone could point staging at prod's state shrinks to one CI parameter instead of a hardcoded line per directory.

Avoiding Copy-Paste Drift

The failure these patterns prevent is concrete: a fix applied to prod/main.tf but forgotten in staging/main.tf, so the environments quietly diverge in a way no one notices until staging stops predicting prod. Pushing all logic into modules/ removes the surface where the two can diverge at all — there is no main.tf resource block to fix in two places, only a module to fix once.

What is left after that is intended difference, and it lives in .tfvars where it is visible. Drift becomes a thing you choose, line by line, in a values file, rather than a thing that happens to you because two copies of the same resource fell out of sync. The structure carries the sameness; the .tfvars carries the difference.

Not Over-Abstracting

DRY has a ceiling. A module so parameterized that every value is a variable and the call site is unreadable is worse than a little duplication — you have traded copy-paste drift for a module nobody can reason about, where fifty inputs hide what an environment actually deploys. When the module's inputs outnumber its readers' patience, the abstraction has gone past the point of clarity.

Some genuine per-environment divergence belongs as explicit config, not another conditional flag. A prod-only disaster-recovery replica is clearer as a resource in the prod directory than as a create_dr_replica variable threaded through the module and defaulted off everywhere else. Stop abstracting when the next variable makes the module harder to read than the duplication it removes; a little honest repetition beats a parameter maze.