Make Terraliths a Thing of the Past – Enable Scalable Root Modules in OpenTofu
### Community note > [!TIP] > 👋 Hi there, OpenTofu community! The OpenTofu team prioritizes issues based on upvotes. Please make sure to upvote this issue and describe how it affects you in detail in the comments to show your support. ### OpenTofu Version ```shell All Versions ``` ## The problem in your OpenTofu project ### Background This issue is the result of ongoing discussions and collaboration between myself (Matt Gowie) and Malcolm Matalka (@orbitz) of Terrateam. We've both been thinking + talking about how OpenTofu could evolve to better support large-scale infrastructure and eliminate the common bottlenecks Terraliths create. This is our attempt to start a deeper conversation and push forward meaningful improvements to OpenTofu. ### Problem: The Monolithic Root Module A common starting point in managing infrastructure with OpenTofu is to define everything in a single root module. This is what a lot of us in the industry call a *Terralith* — a term used to describe a monolithic root module where too many resources live under one giant state file. It’s a setup that feels fine… until it doesn’t. Eventually, you hit major blocker issues: * **Plan/apply performance suffers** as the entire infrastructure is refreshed and evaluated. * **Concurrency breaks down**: even teams working on unrelated changes are blocked due to state operations being forced to run one at a time, like transactions in a database. * **State locking kills velocity**, and the lack of cr
Posted by Gowiem on May 26, 2025, 3:55 PM
Tags
Related issues
- The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
- I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
- I hate that I'm in deep enough to know what you mean.
- The biggest problem with “AI” is that big corps are shoving it down our throats.
- in the middel of a coding session with 5.6 sol.
- [Hero Run] 535B-A23B on 18T tokens
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
reliability (Other)
The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
I hate that I'm in deep enough to know what you mean.
The biggest problem with “AI” is that big corps are shoving it down our throats.
in the middel of a coding session with 5.6 sol.
[Hero Run] 535B-A23B on 18T tokens
I hate that this is how AI is being used..
inexperienced protobuf user here -- why do non-googlers generally use protobuf?
Make Terraliths a Thing of the Past – Enable Scalable Root Modules in OpenTofu
### Community note > [!TIP] > 👋 Hi there, OpenTofu community! The OpenTofu team prioritizes issues based on upvotes. Please make sure to upvote this issue and describe how it affects you in detail in the comments to show your support. ### OpenTofu Version ```shell All Versions ``` ## The problem in your OpenTofu project ### Background This issue is the result of ongoing discussions and collaboration between myself (Matt Gowie) and Malcolm Matalka (@orbitz) of Terrateam. We've both been thinking + talking about how OpenTofu could evolve to better support large-scale infrastructure and eliminate the common bottlenecks Terraliths create. This is our attempt to start a deeper conversation and push forward meaningful improvements to OpenTofu. ### Problem: The Monolithic Root Module A common starting point in managing infrastructure with OpenTofu is to define everything in a single root module. This is what a lot of us in the industry call a *Terralith* — a term used to describe a monolithic root module where too many resources live under one giant state file. It’s a setup that feels fine… until it doesn’t. Eventually, you hit major blocker issues: * **Plan/apply performance suffers** as the entire infrastructure is refreshed and evaluated. * **Concurrency breaks down**: even teams working on unrelated changes are blocked due to state operations being forced to run one at a time, like transactions in a database. * **State locking kills velocity**, and the lack of cr
Comments (0)
No comments yet. Start the discussion.