Terraform at Scale: State Boundaries & Modules (2026)

Q: How should Terraform state be split for a large organisation?

Split state along two axes: who owns and is allowed to change the resources, and how often they change. A practical default is four layers: foundation (accounts, org policies, identity), network and shared services, per-service infrastructure owned by product teams, and ephemeral preview environments. Values flow down through deliberately published outputs, so each state has one owner, a predictable change rate and a limited blast radius.

Q: Why is one Terraform state per environment a problem?

Because locking, plan time, blast radius and access control are all per state. A single production state serialises every team's changes behind one lock, refreshes thousands of resources on every plan, lets any apply touch the network, databases and DNS together, and gives anyone who can read it access to every sensitive attribute inside. It works for small estates but breaks once several teams change infrastructure daily.

Q: What are Terraform Stacks and are they generally available?

Terraform Stacks are an HCP Terraform feature for orchestrating multiple Terraform configurations. Components define modules that share a lifecycle, deployments represent environments, accounts or regions, and linked Stacks pass outputs to dependent Stacks and trigger their runs. HashiCorp announced general availability for new HCP Terraform plans at HashiConf in September 2025. The documentation currently lists limits such as 20 deployments and 10,000 resources per Stack.

Q: Terragrunt vs Terraform Stacks: which should a platform team use?

If you already run HCP Terraform and your layers fit within the documented Stack limits, Stacks give first-party orchestration and downstream run triggers. If you want open-source tooling across many small root modules, or need to stay portable to OpenTofu, Terragrunt or a similar wrapper is a reasonable choice. Below roughly fifty states, plain CI with a dependency file is often enough. Fix state boundaries first; no orchestrator fixes bad ones.

Q: How do you move resources between Terraform states without recreating them?

Within a single state, use a moved block to change a resource's address declaratively. Across states, add the resource configuration and an import block to the destination state and apply it, then add a removed block to the source state that forgets the object without destroying it. Require plans showing zero creates and zero destroys at every step, add prevent_destroy to stateful resources first and back up state before each batch.

Q: How should Terraform modules be versioned at platform scale?

Treat modules as products: follow the standard module structure, publish to a private registry with semantic versions and pin every consumer to a version range, never a branch. The hard problem is propagation, so automate version-bump pull requests with the plan attached, track the version spread across all states as a platform metric and keep modules thin, encoding platform decisions rather than exposing dozens of flags.

Q: Should we migrate from Terraform to OpenTofu or Pulumi to fix scaling problems?

Not to fix scaling problems. Lock contention, slow plans and unclear ownership come from how state is divided, and a new tool ports a badly drawn state unchanged. Decide tooling separately on licensing, ecosystem and features, such as OpenTofu's built-in client-side state encryption. Note that with encryption enabled, state is unrecoverable without the key, so key management becomes part of your disaster recovery plan.

Q: When should you not split Terraform state into layers?

When the estate is small, roughly a few hundred resources managed by one or two teams, a state per environment is simpler and the extra wiring of layers costs more than it saves. Split when you can measure real lock contention, long plan times or applies crossing team ownership. Also keep application releases out of Terraform entirely; frequently changing image tags belong in the delivery pipeline, not in infrastructure state.

Satyam Kumar

Volver al Blog

ai-architecture

Terraform at Platform Scale: State Is the Unit of Blast Radius, So Split It by Who Changes What and How Often, Not by Environment (2026)

By Satyam KumarOctober 14, 202612 min read

terraform at scale terraform state management terraform stacks terraform state splitting infrastructure as code platform opentofu state encryption terraform module versioning terraform monorepo structure terragrunt vs terraform stacks terraform moved block terraform import block iac blast radius platform engineering iac terraform drift detection hcp terraform platform engineering 2026

Terraform at Platform Scale: State Is the Unit of Blast Radius, So Split It by Who Changes What and How Often, Not by Environment (2026)

Frequently Asked Questions

Compartir este artículo

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Arquitecto de IA y Cloud. Ayudando a equipos a construir sistemas que escalan a millones.

LinkedIn GitHub

Terraform at Platform Scale: State Is the Unit of Blast Radius, So Split It by Who Changes What and How Often, Not by Environment (2026)

Frequently Asked Questions

Compartir este artículo

Comments

Leave a comment