Terraform’s state is its memory. Where you store that memory determines how safely and collaboratively you can operate. Local state is fine for solo sandboxes; remote state is how teams avoid collisions, preserve history, and build reliably. In this chapter, you’ll learn the trade-offs, when to use each, and how to transition without drama.

Local state

terraform.tfstate on your machine

• What it is: Terraform writes a JSON file to your working directory.
• Pros:
  • Simplicity: Zero setup; great for quick prototypes.
  • Speed: No network round-trips.
  • Isolation: Experimental changes don’t affect team workflows.
• Cons:
  • No collaboration: Only you see changes; risk of drift across teammates.
  • Fragility: Easy to lose/corrupt; backups are manual.
  • Security risk: Sensitive outputs live in plaintext on local disk.
  • No locking: Concurrent runs can corrupt state.

Remote state

stored in a backend service

• What it is: State is kept in a shared, durable store (S3, GCS, Azure Blob, etc.).
• Pros:
  • Collaboration: Single source of truth for teams and CI.
  • Locking: Prevents concurrent writes with backend-supported locks.
  • Durability & recovery: Versioning, backups, access controls.
  • Audits: Cloud logs and IAM policies for governance.
• Cons:
  • Setup overhead: Buckets, tables, permissions need configuration.
  • Network dependency: Requires access and latency considerations.
  • Complexity: More moving parts (credentials, regions, keys).

Decision Guide

• Use local state if:
  • Solo learning/lab: Disposable experiments and quick spikes.
  • Isolated PoCs: No shared environments; you’ll soon migrate if it succeeds.
• Use remote state if:
  • Team environments: Multiple engineers or CI/CD apply changes.
  • Shared infra: Networking, databases, or prod systems.
  • Compliance/security: Need access control, audit trails, backups.

Hands‑On Lab / Demo

1) Start with local (baseline)

• Create: A simple EC2 resource in main.tf.
• Run:
  • terraform init
  • terraform apply
• Observe: terraform.tfstate appears locally; try terraform state list.

2) Configure remote backend (example: AWS S3 + DynamoDB)

• Add backend.tf:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-123"
    key            = "dev/app/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

• Initialize migration:
  • terraform init → approve migration from local to remote.
  • terraform plan → confirm state reads from remote.
  • terraform apply → validate locking works (try opening a second terminal).

3) Verify remote usage

• Check:
  • State no longer updates locally.
  • S3 shows versioned objects; DynamoDB shows locks during apply.

Pro Tips & Best Practices

• State separation:
  • Label keys clearly: env/app/component/terraform.tfstate.
  • Split by domain: network, compute, data to avoid a single giant state.
• Security & access:
  • Least privilege IAM: Restrict read/write to relevant engineers and CI.
  • Encryption: Enable SSE on buckets; prefer customer-managed keys where required.
• Reliability:
  • Versioning: Turn on object versioning for rollbacks.
  • Locking: Use DynamoDB (AWS) or built-in locking where supported.
• Operational hygiene:
  • Don’t edit state by hand: Use terraform state subcommands.
  • Backups: Snapshot remote state before major refactors.
  • Credentials: Avoid hardcoding; use profiles or short-lived tokens.

Quick reference

• Local: Simple, fast, non-collaborative.
• Remote: Shared, locked, durable, team-ready.
• Commands:
  • Init/migrate: terraform init
  • Inspect: terraform state list, terraform state show <addr>
  • Plan/apply: terraform plan, terraform apply

The Hackers Notebook

Choosing local vs remote state is about maturity and teamwork. You’ve learned when simplicity wins and when safety, locking, and durability matter. With remote backends in place, you’re ready to operate like a team: consistent, auditable, and resilient.