We're still figuring out what balance makes sense between openness and sustainability, and we'd rather take the time to get it right than rush into a license we'll regret later. The goal is for Stategraph to last a long time.
Definitely agree. Most teams don't choose a language for purely rational reasons, and we're not pretending we did.
We like OCaml, it makes us excited to build. We know the language deeply, which means we can reason about performance and behavior before we run the code. We can onboard new engineers quickly because the type system forces clarity.
The runtime is simple enough that we can predict what it's doing. So yes, part of it is that OCaml feels good to use. But that feeling comes from years of watching it make complex systems simpler to reason about, not harder.
Terrateam builds GitOps automation for Terraform and OpenTofu. We help large engineering teams plan, review, and apply infrastructure changes safely, directly from GitHub and GitLab pull/merge requests.
We are looking for a Software Engineer who can move between backend systems, infrastructure, and open source tooling. You'll work on Terrateam's OCaml core, support customers, and contribute to the design of next-generation Terraform orchestration.
You might be a good fit if you:
- Care about correctness and reliability in complex systems
- Have experience with infrastructure automation, CI/CD, or compilers
- Enjoy working in OCaml or another strongly typed functional language
- Value autonomy and precision in engineering
Stack: OCaml, Postgres, Docker
Team: small, remote, and technical
Comp: €90k–€130k depending on experience
We are based in Amsterdam and work async across EU and US time zones. Preference for EU timezones.
I have 5 years of experience working with Terraform in complex, critical business settings across multicloud environments, including Chinese cloud providers. I'm based in Poland. My background includes infrastructure automation, CI/CD pipelines, and building reliable systems with Java and Python. I haven't used OCaml in production yet, but I have solid functional programming experience and I'm eager to learn.
Is commercial experience with Ocaml hard requirement?
what's lame about it? I read the comments specifically for alternative tools. Often times, commenters provide links to other tools and nobody has ever complained...until you came along
Terraform Cloud does not actually solve this. It moves the state into their service and manages locking centrally, but the underlying model is unchanged. It is still one file with a global lock. That is why refresh bottlenecks and contention show up there too. What we are pointing at is the model itself, not just where the file is hosted. We know this space well from building Terrateam, which competes with Terraform Cloud on orchestration.
Hi Alex. Great question and definitely something top of mind as we build Stategraph. The short answer is there is always a service layer in front of the database. Users and teams interact with that service, not the database directly. That is where access control and ownership boundaries live.
From my experience the problem at scale isn't that Terraform stops being useful. The problem is how state gets managed. Every IaC approach still has to coordinate changes across shared resources and none of them escape that. Other tools just shift the trade offs around. In house systems usually end up rebuilding the same thing in another form.
At scale the choices are pretty simple. You split state and live with orchestration glue. You move to a controller model and take on the operational overhead (see Crossplane). Or you keep a cohesive graph and fix the state layer. Those are the real options (imo). It's not about outgrowing Terraform.
Changes across shared resources should be few and far between. Terraform really should only be used to setup long-lived resources, such as your VPC, initial IAM, and a bootstrapping system/management plane (eg, your kubernetes cluster). Once your infrastructure is up and running, further operations should be api-driven (aka controllers).
I'm not really a fan of crossplane, it's much simpler to roll your own custom operator, especially now that things like the Azure Service Operator exist (I think there's something equivalent for aws as well). This gives you a lot more flexibility for writing unit tests for your business logic.
Agreed. One of the frustrating things about using Terraform or OpenTofu is that all the data is sitting there in state but you can't really query or report on it. Making that information accessible is a big part of why we are building this.
We are already in that space [0] though that's not the focus of this post. Working with teams at scale on orchestration is what pushed us to look deeper at state itself and eventually create this project.
