Terragrunt is dead: Multi-state transactions killed run-all
Terragrunt is dead. Multi-state transactions execute dependent states as a single atomic operation. No run-order orchestration. No sequential plan/apply cycles. The entire coordination layer becomes obsolete.
When we say "orchestration is dead," we're talking about run-order orchestration. That's the scripts, directories, and run-all logic that exists solely to force Terraform to execute states sequentially. This is the glue code you write because Terraform can't reason across state boundaries. Multi-state transactions eliminate that constraint. The engine handles dependencies natively. Policy orchestration, governance, approvals, and workflow management still matter. But the procedural coordination layer, the thing Terragrunt was built for, disappears.
If you've scaled Terraform to any serious size, you've hit this wall. You split infrastructure across multiple state files. Module A outputs values that module B consumes via terraform_remote_state. Now you need orchestration. Plan A, apply A, then plan B with A's outputs, then apply B. Repeat for every dependency chain.
This is why Terragrunt exists. To manage the graph that Terraform refuses to see. Terragrunt is run-order orchestration. It exists because Terraform has no concept of cross-state dependencies.
But Stategraph sees the graph. Because in Stategraph, state isn't a file. It's a database. Different state IDs are just rows in the same system. Which means we can do something Terraform never could. We can execute a transaction across multiple states.
The run-order orchestration tax
Consider the standard multi-state workflow. You have root module A (a VPC) and root module B (an application that needs the VPC ID). In traditional Terraform:
This isn't just annoying. It's fundamentally broken. You have to commit to applying A before you can see its real impact on B. Even if Terragrunt mocks outputs, the actual blast radius remains hidden until after A is applied. You're making sequential decisions without seeing the complete picture. The unified plan you need doesn't exist.
Sequential Orchestration
6 operations
Sequential execution
Incomplete visibility
Multi-State Transaction
1 operation
Atomic execution
Complete visibility
Amdahl's Law strikes again
As Amdahl taught us in 1967, you can never be faster than your slowest sequential operation. No matter how fast Stategraph makes individual state operations, if you're forced to chain them sequentially with external coordination scripts, the run-order orchestration overhead dominates.
Terragrunt works around this by building a dependency graph from directory structure and dependency blocks. It runs Terraform processes in topological order, wiring outputs to inputs. It's sophisticated procedural orchestration. It works. But it's all external to the Terraform engine—a coordination layer that only exists because the engine can't handle cross-state dependencies.
Multi-state transactions: The native solution
Stategraph can do better. Because in Stategraph, states A and B aren't separate files on separate S3 buckets. They're rows in a database under the same tenant. We can construct a single transaction that includes both.
The workflow becomes:
One transaction. One plan. One apply. The run-order coordination disappears into the engine.
The blast radius problem finally solved
Here's where multi-state transactions get really interesting. Say you change something in module A. With traditional orchestration, you don't see how that impacts module B until after you've applied A. Too late.
With multi-state transactions, you see everything:
Even better: if you have module C that depends on B, and you forgot to add it to the transaction, Stategraph can still show you the impact. Because all states live in the same database, the engine can traverse the dependency graph and warn you about downstream effects you haven't included.
Sequential: Incomplete Visibility
Can't see downstream impact
Transaction: Complete Visibility
Complete dependency graph visible
The correct plan, finally
Multi-state transactions give you what Terraform always promised but never delivered. A plan that accurately reflects what will happen when you apply. No surprises. No "well the plan looked fine but then the second module failed." Just correct, atomic operations.
What becomes possible
Once you eliminate run-order coordination overhead, the economics of multi-state infrastructure change completely.
Filesystem organization without performance penalty. Want to split your infrastructure across directories for clarity? Go ahead. There's no coordination tax. The transaction combines them automatically.
Faster iteration cycles. No more running terraform apply four times to see if your cross-module change works. One transaction, one cycle.
Reduced cognitive load. You don't need to hold the dependency graph in your head or maintain procedural ordering. Add the modules you're changing to a transaction. Stategraph figures out the order.
Safer changes. See the complete blast radius before applying anything. No more "I changed the VPC and broke production without realizing."
The Economics Change
Orchestration Overhead
Atomic Transaction
5× faster iteration. Zero orchestration overhead.
The end of run-order orchestration
Terragrunt solved a real problem. Organizations needed a way to coordinate Terraform across multiple states, and Terraform refused to provide native solutions. Terragrunt filled the gap with external, procedural orchestration.
But it was always compensation for a missing primitive. The state model itself couldn't handle cross-state dependencies. So we built coordination scripts, directory conventions, and run-order logic on top to simulate what should have been native behavior.
Multi-state transactions make that coordination layer obsolete. Not by adding another wrapper, but by fixing the primitive. State as a graph database. Transactions across multiple state IDs. Automatic dependency resolution. Native blast radius calculation.
Terragrunt revealed what Terraform needed to become. Stategraph builds it.
The goal isn't to build a better run-order orchestration tool. It's to eliminate the need for procedural coordination entirely by making the engine smart enough to handle cross-state dependencies natively.
When the primitive is right, the glue code disappears. Policy orchestration, governance, and workflow management still matter. But the scripts that exist only to sequence Terraform operations? Those are dead.
Stop coordinating, start shipping
Multi-state transactions are coming to Stategraph Velocity. If you're tired of orchestrating Terraform across dozens of state files, we should talk.
// Zero spam. Just progress updates as we build Stategraph.