Engineering Log: Stategraph 1.0.0 and the month that made it real
A 1.0 is a statement about confidence and precision. It means the software is ready for real workloads and handles them correctly. For a tool that operates on Terraform state, both took a lot of work to earn. This month we got there.
What 1.0.0 actually means
Stategraph 1.0.0 shipped on March 20. The system handles real-world Terraform reliably and we are willing to stand behind it.
Stategraph has to correctly handle whatever Terraform configuration you give it. Every HCL pattern, every variable file, every provider quirk. If any of that is wrong, the dependency graph diverges from reality, and the plans you get back are wrong too. Calling something 1.0 means we trust that it won't.
Stategraph 1.0.1 shipped six days later on March 26 with improvements to stategraph import tf, including better error messages, smarter defaults, and validation that catches misconfiguration early.
We also shipped APT and RPM packages. Installing Stategraph on Debian, Ubuntu, RedHat, or CentOS is now a single package manager command.
Design Principle
Stable does not mean finished. It means the system has been tested against enough real-world infrastructure that we trust it will not silently produce wrong results.
Broader HCL coverage
HCL has grown alongside Terraform's provider ecosystem for years, and real-world configurations use the full surface area of the language. A construct that Stategraph cannot understand is a construct it cannot include in the dependency graph.
This month we expanded coverage for patterns that show up in production Terraform. Provider-defined functions, multiline expressions, and edge cases in how certain constructs interact with modules.
We also fixed a bug where for_each inside module blocks was not being handled correctly. Modules with for_each are a common pattern for deploying the same infrastructure across multiple environments or regions, so getting it wrong means missing dependencies in the graph.
Observation
HCL compatibility is not a problem you solve once. Every new provider and every Terraform release can introduce new patterns. The parser has to keep up with whatever your infrastructure actually uses.
Variables all the way down
Terraform's variable resolution has a specific precedence order. Environment variables (TF_VAR_*) are overridden by terraform.tfvars, which is overridden by *.auto.tfvars files in lexical order, which are overridden by -var and -var-file flags on the command line. If Stategraph gets any part of that order wrong, the blast radius it calculates will differ from what Terraform actually applies.
Full tfvars support landed this month. Stategraph now resolves all of the above, following Terraform's exact precedence.
More importantly, variable changes are now included in blast radius calculation. When a tfvar value changes, Stategraph traces which resources depend on that variable and includes them in the affected subgraph. If you manage environment-specific configuration through tfvars (most production setups do), the blast radius now reflects those changes too.
Implementation Detail
Variable resolution precedence is a correctness requirement. If Stategraph resolves a variable to a different value than Terraform would, every downstream calculation is wrong. Getting this exactly right is what earns trust.
What's next
1.0 is the foundation. The hard part was making sure Stategraph handles real-world Terraform correctly and completely. Now we're building on that foundation with a faster release cadence. 1.0.1 shipped in six days. Expect that pace to continue.
If you are managing Terraform at scale and want faster plans, parallel execution, and cross-state transactions, request access and try it yourself.