Why Terramantle has no runners, and never will

There is a moment in every infrastructure platform demo where an agent gets installed. It is usually slide fourteen, after the nice dependency graph and before pricing. A helm chart goes into your cluster, or a binary onto a host, and it needs credentials broad enough to apply any change any of your workspaces might make. Everyone in the room nods, because this is just how the category works now.

I want to argue that the nodding is the problem. "We run your Terraform for you" became the default architecture of IaC platforms without anyone really justifying it, and for a lot of teams it is a cost they are paying without noticing.

What you are actually installing

Start with what that agent has to be able to do. It runs apply for every workspace, which means it holds, or can assume, the union of every permission every workspace ever needs. In practice that rounds up to admin. You have taken the broadest credential in your cloud account and handed it to a third-party component that runs continuously inside your network.

That component is now several things at once, and none of them are comfortable. It is a concentration of privilege, the single most powerful identity in your environment. It is a store of credentials, because even if they are encrypted at rest, encrypted-at-rest is still stored, still sitting there, still one platform compromise away from being someone else's. It is a new attack surface, a persistent, outbound-connected, elevated-privilege process that your security team now has to threat-model, patch, and watch forever. And it is a supply-chain dependency, because you have inherited the vendor's entire build pipeline for a thing that can rewrite your infrastructure.

Put plainly: an incident at the platform is now an incident in your cloud accounts. You did not used to have that coupling. The agent created it.

The part that actually annoys me

Here is what tips this from "a tradeoff" to "backwards" for me. Most teams evaluating these platforms already have working CI/CD. They have GitHub Actions or GitLab CI, they have federated credentials over OIDC, they have approvals and audit and a way to run plan and apply that they have already hardened and already trust.

And the platform asks them to rebuild all of it somewhere else. The credential handling you got right, the approval flow you tuned, the audit trail your compliance people already accepted, you are asked to move all of it into a vendor's runner so the vendor can be the thing that runs your Terraform. You are not filling a gap. You are relocating capability you already had into a place that is harder to reason about.

Where I will concede the point

I do not think runner-based platforms are a scam, and I want to be careful here because the honest version of this argument has to hold the counterexample.

If your CI/CD is weak or nonexistent, an execution platform is genuinely a good buy. It gives you run queues, drift detection, a real approval workflow, and policy-as-code gates on every apply, all in one place, without you having to assemble it from parts. For a team that does not have those things and does not want to build them, having the platform own execution is a feature, not a liability. The concentration of privilege is a real cost, but you are getting real capability for it.

The disagreement is narrower than "agents are bad." It is that teams who already have strong pipelines are being asked to hollow them out to adopt a platform, and the thing they are giving up, control of execution and custody of their own credentials, is worth more than what most of them get back.

The bet we made instead

So Terramantle does not run your Terraform. Not "runs it more securely," does not run it at all. It is the registry and the state layer, and nothing else. Your pipelines keep running plan and apply exactly where they run today, with the credentials and approvals you already trust, and they pull modules, providers, and state from Terramantle over OIDC. Nothing in Terramantle ever holds your cloud credentials, because it never needs them. There is nothing to run, so there is nothing to install, so there is no agent to threat-model.

The consequence I care about most is what this does to a security review. When the reviewer asks where your cloud credentials live, the answer is one line: they never leave your pipeline. There is no encrypted-variable store to audit, no runner to pen-test, no vendor blast radius to bound, because the vendor is a registry that hands out tarballs and state, not a process with keys to your account. Adoption is a source-address change and a backend block, not a migration project, because we are not asking you to move your execution anywhere.

The principle

The way I would put the design principle: a registry should be infrastructure your pipelines consume, not a platform that consumes your pipelines. The moment a tool needs your credentials to do its job, it has become the most dangerous thing in your environment, and it should have to earn that on merits, not inherit it because the category defaulted to it.

If you have strong pipelines, keep them. Add a registry that stays in its lane.

I wrote the version of this you can hand to a security reviewer, with the six concerns laid out to be lifted straight into a vendor assessment, on the no runners architecture page. This was the opinion; that is the document.