Interface-only solutions

A recent Infrastructure as Code newsletter outlined something a lot of us have been feeling: IaC was supposed to make infrastructure delivery faster, but somehow we're still stuck in the same old bottlenecks. Sure, interfaces have gotten better and tooling has improved, but development teams are still waiting around while platform teams get overwhelmed trying to keep up. Meanwhile, environments keep getting more fragmented and delivery just doesn't happen as smoothly as it should.

The article points to interface problems as the main culprit, and there's definitely truth to that. Developers really don't want to learn Terraform's DSL (I get it...). Fighting with YAML, HCL, and these domain-specific languages that feel so disconnected from the actual systems you're building gets old fast. So naturally, the industry has been trying to fix this with new abstractions. Pulumi and CDK let you use real programming languages. Winglang (RIP) and Ampt tried to embed infrastructure right inside your application code. System Initiative and ConfigHub are going for visual models and drag-and-drop interfaces. And now LLMs are promising you can just describe what you want in plain English.

But I think we're missing something here. What if the interface issues are just symptoms of a deeper problem?

Terraform wasn't designed for delivery

A few months back, we were talking with a platform team at a large fintech company. Their Terraform setup was actually really impressive (clean modules, plans running in CI, etc.). It looked great on paper, but their developers were still having to create tickets and wait for manual approvals, just to get environments provisioned. They'd built this whole automated system that somehow still needed humans to manually unlock operations at every step. Their delivery process wasn't really mature at all.

Terraform was never actually designed to be part of a delivery system. It was built to provision infrastructure, and that's a pretty important distinction that goes way beyond just semantics.

Think about how Terraform actually works. Each run is basically stateless (and I don't mean state files here). What I mean is that every plan and apply runs in complete isolation, with no memory of what happened before or any understanding of the bigger picture around delivery. They're designed to execute their task and then just exit. They don't leave any trace of why they were run in the first place. They don't really understand environments, or track changes over time, or have any context beyond that single plan file they're working with. They can't orchestrate across different workflows or teams, and they don't persist any meaningful state beyond just that last snapshot.

So when a team brings in Terraform, they're getting a really powerful provisioning engine. But provisioning is just one piece of the delivery puzzle. If you want to turn infrastructure into something that actually supports smooth delivery, you still need to handle all the orchestration stuff yourself. That usually means cobbling together CI pipelines, policy checks, environment management, drift detection, and lots of other things either manually or through a bunch of different external tools. This is exactly where teams start hitting friction, and it's why we built Terrateam in the first place.

Why Terrateam exists

That gap is what Terrateam was designed to fill. And it's not because Terraform is bad. It's actually quite the opposite. Terraform is pretty elegant precisely because of its constraints. But those constraints are real, and the provisioning-only design starts to show its limits when you need infrastructure to behave more like software and when teams need actual workflows.

OpenTofu's opportunity

Which brings us to OpenTofu. Here's a fork that has a real future ahead of it, no commercial strings attached, and a really active community full of people with strong opinions about where things should go.

OpenTofu has this pretty rare opportunity right now. It could stay on the path of being a better version of Terraform. Or it could evolve into something fundamentally different. Something that doesn't just run a plan or apply and then disappear. Instead, it could become a long-running system with a proper graph engine and delivery orchestration built right in.

Orchestrated IaC

OpenTofu could be more useful with proper environment management. Actual lifecycle controls, TTLs, and ownership tracking instead of just basic workspaces. Environment specific policies and approval workflows would help manage the usual preview/staging/production progression.

Better change tracking would be helpful too. Capturing context around why changes happened, not just the diffs. Who approved what, which validations ran, when drift was detected.

Adding proper APIs and webhook support would make integration easier. Better git integration built into the core tool rather than requiring external scripting would streamline workflows.

Competition

We've already built this server at Terrateam. We're living in the future where orchestration exists, where teams can express intent through pull requests, and where infrastructure delivery actually works smoothly. But we'd love to see OpenTofu evolve in this direction too.

Having these capabilities built into the core tool would make the entire ecosystem stronger. It would let us integrate more deeply instead of working around current limitations. It would give teams more choices. And it would validate what we've been saying all along, that the real problem isn't syntax, it's the lack of stateful orchestration.

We're not worried about competition here. The market is huge, the problems are real, and there's room for multiple approaches. What matters is moving the whole field forward.

This should be the evolution

It's tempting to just build yet another wrapper script, another workflow file, another CLI abstraction. But we've all seen where that road goes. Teams end up burning cycles maintaining glue code that shouldn't need to exist in the first place. Every organization winds up reinventing the same half-finished orchestration layer over and over again. It's such a waste of talent and attention.

The whole field benefits when the core primitives actually evolve. When infrastructure stops being something you have to file tickets for and becomes just another pull request with proper policy controls. When spinning up ephemeral environments isn't some special case but just normal operation. When audit trails are built in from the start. When teams can express what they want and actually see it happen. Governed, observed, and safe.

Terrateam is going to keep building toward that vision. We exist because teams need orchestration right now. And if OpenTofu starts growing in that direction, we'll be there to meet it. We'll integrate with it, extend it, contribute to it.

This isn't about protecting some business moat. It's about finally breaking down this artificial wall between infrastructure and delivery. It's about demanding more from our tools. And it's about shifting the conversation away from whether HCL is too hard to write toward whether the engine behind it can actually handle the job we're asking it to do.

Delivery is the destination

The future of Infrastructure as Code isn't going to be won by making the syntax friendlier. It's going to be won by systems that actually understand delivery from the ground up. Terrateam is building that system today, and we really hope OpenTofu decides to join us.

Features

Learn More

Learn

Connect