Terraform is forgiving in the first few weeks and unforgiving after that. A messy structure that one person can hold in their head becomes a real problem the moment a second engineer needs to touch it, or the moment terraform apply runs somewhere other than a laptop. These are the decisions worth making early, before there's a team depending on them.
Put state somewhere shared, immediately
Local state — a terraform.tfstate file sitting on one machine — works right up until two people run apply on the same day, or that laptop's disk fails. Move state to a remote backend from the first commit:
terraform {
backend "s3" {
bucket = "your-project-tfstate"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
The dynamodb_table line matters as much as the bucket — it's what stops two applies from racing each other and corrupting state.
Never commit .tfstate or .tfvars with real secrets
State files can contain resource attributes you don't want in git history, and .tfvars files are where real database passwords and API keys end up if you're not careful. Add both to .gitignore on day one:
*.tfstate
*.tfstate.backup
*.tfvars
.terraform/
Secrets belong in a secrets manager or your CI provider's encrypted variables — not interpolated into a .tf file, even one that's gitignored on your machine but not on someone else's.
Separate environments by directory, not by branch
A single main.tf with variables that switch behavior based on a workspace name is a common early shortcut, and it's the thing that eventually causes a dev change to accidentally apply to prod. A directory per environment, each with its own state and its own explicit terraform apply, is more files but far fewer ways to make that mistake:
infra/
modules/
network/
database/
service/
environments/
dev/
main.tf
staging/
main.tf
prod/
main.tf
Each environment composes the same modules with different inputs. The blast radius of a mistake in dev stops at dev.
Write modules before you have a second use case
It's tempting to wait until you're duplicating code before extracting a module. In practice, a module written from the start — even for something you're only using once today — forces you to define a clean interface (inputs, outputs) instead of a pile of resources with implicit dependencies on each other. That interface is what makes the second environment fast to add later.
Require a plan review before apply, even solo
terraform plan output in a pull request, reviewed before apply runs, catches a category of mistake that's easy to miss reading the .tf file alone — a resource getting replaced instead of updated, a variable that resolved to something unexpected. This is worth setting up in CI even when you're the only one committing; the review habit is what carries over cleanly once a second person joins.
Check for drift on a schedule
Infrastructure changed by hand in the console — a security group rule added during an incident, a setting tweaked to unblock a deploy — silently diverges from what Terraform thinks is true. A scheduled terraform plan in CI, even just posting its output somewhere visible, surfaces that drift before it causes a surprising apply months later.
None of this is complicated in isolation. The value is doing it in week one, while the cost of changing your mind is a few file moves — not a migration project once three environments and a team depend on the structure you started with.
If you're setting this up for the first time and want a second pair of eyes on the structure before it calcifies, that's exactly the kind of early-stage review our DevOps consulting engagements are built for.
