Terraform treats every state as an island
Coordinating a change across networking, compute, and application states means applying them one at a time, in the right order, hoping nothing fails halfway. There's no atomicity across the boundaries you drew.
One plan across two states
rm1 and rm2 are separate root modules with separate states. One stategraph tf mtx plans both — 7 resources across State 0 and State 1 — and one apply commits them together.
❯ stategraph tf mtx ./rm1 ./rm2 -- plan State 0 · ./rm1 + terraform_data.network + terraform_data.subnet + terraform_data.router State 1 · ./rm2 (reads rm1.network_id, pending) + terraform_data.app + terraform_data.firewall + terraform_data.route + terraform_data.dns_record Plan: 7 to add, 0 to change, 0 to destroy # across 2 states ❯ stategraph tf mtx ./rm1 ./rm2 -- apply State 0 ✓ applied State 1 ✓ applied ✓ transaction committed · 7 resources · 2 states · 1 txn
State 0 = rm1, State 1 = rm2 · one plan, one apply, one transaction
What you get
Atomic commits
Every state in the transaction applies together, or none does. No more half-applied changes across module boundaries.
Automatic dependency order
Cross-state references resolve automatically. Stategraph orders the work for you — no hand-maintained apply sequence.
One plan, full picture
See every change across every state in a single plan, with real diffs. Review the whole change set at once.
Reads pending changes
Consumers see producers' planned outputs in the same transaction. See cross-state plans →
No partial-failure cleanup
A failure anywhere rolls the whole transaction back. You never wake up to a state that's half-migrated.
Same HCL
Point each module's backend at Stategraph and run stategraph tf mtx across the directories. No code changes.
Apply across modules, atomically
Stop ordering applies by hand and praying nothing fails halfway. See all features →