Privilege concentration
A runner needs the union of every permission every workspace ever applies with. In practice that is admin-level cloud credentials, delegated to a third-party component and held in one place.
Architecture
No runners. No agents. Your pipelines, your credentials.
Most infrastructure-as-code platforms work by running your Terraform for you. That means installing their runner inside your network, or shipping your cloud credentials to their SaaS. Terramantle does neither, because it never executes your Terraform. This page is written so you can lift the concerns section straight into a vendor security review.
How they work
How runner-based platforms actually work.
A TACOS or Terraform Enterprise runs plan and apply on your behalf. To do that, a runner or agent runs inside your network (or your credentials are copied to the vendor), holding enough privilege to change your infrastructure. This is accurate and neutral, it is genuinely how the category works, and for some teams it is the right shape.
flowchart LR
subgraph yours["Your network"]
CI["Your CI/CD"]
end
subgraph vendor["Vendor SaaS"]
P[Platform]
A["Runner / agent"]
V[("Encrypted vars:<br/>cloud credentials")]
end
A -->|holds| V
A -->|apply| Cloud[("Your cloud accounts")]
P --> A
CI -.->|installs, trusts| AFor your security review
Six costs of the run-it-for-you model.
None of these say runner-based products are insecure. They say the model carries a cost, and many teams do not need to pay it. Copy this section into a vendor assessment as-is.
Static credential storage
Those credentials sit in the platform’s encrypted variables. Encrypted at rest is still stored, still exfiltratable by a compromised platform, and still one breach away from being your breach.
A new attack surface inside the perimeter
The agent is a persistent, outbound-connected process with elevated privileges. Your security team now has to threat-model it, patch it, and monitor it, forever.
Supply-chain exposure
You inherit the vendor’s build pipeline for a component that can apply infrastructure changes in your accounts. Their compromised dependency becomes your compromised apply.
Duplicated investment
Most teams have already built credential handling, OIDC federation, approvals, and audit into their CI/CD. A runner-based platform asks them to rebuild all of it somewhere else.
Vendor blast radius
An incident at the platform becomes an incident in your cloud accounts. The coupling is the problem, not any one vendor’s competence.
The position
How Terramantle sits beside your CI/CD instead.
Terramantle is the registry and state layer, nothing more. Your pipelines keep running plan and apply 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. The credential-handling section of your security review becomes one line: it never has them.
flowchart LR
subgraph yours["Your network"]
CI["Your CI/CD"]
Cred[("Your cloud creds:<br/>OIDC, stay here")]
end
T["Terramantle<br/>registry + state"]
CI -->|plan / apply| Cloud[("Your cloud accounts")]
CI -->|OIDC pull:<br/>modules, providers, state| T
Cred -.->|never leaves| CIHonest trade-offs
When a runner platform is the right buy.
Execution platforms exist for good reasons. If your CI/CD is weak, or you want a single place that owns run queues, drift detection, policy-as-code gates on every apply, and a managed approval workflow, a TACOS earns its keep and the registry comes bundled. If module and provider distribution is the actual problem you have, a full execution platform is a lot of surface area, and often per-run or per-resource pricing, for one feature. Terramantle is the narrow tool for teams who want to keep execution in their own pipelines. If that is not you, we will happily point you at the platforms that fit.
Related reading: the opinionated version of this argument is in the HCP pricing post, and if you run OpenTofu specifically see the private OpenTofu registry page.
Questions a security reviewer will ask
Does Terramantle run my Terraform?
No. Terramantle is the registry and state layer only. It has no runners and no agents because it never executes your Terraform. Your existing pipelines keep running plan and apply exactly where they run today.
Where do my cloud credentials live?
Wherever they live today, which is in your own CI/CD. Terramantle never holds them. Your pipelines authenticate to your cloud the way they already do, and separately pull modules, providers, and state from Terramantle over OIDC.
Does it replace GitHub Actions or GitLab CI?
No, it complements them. Terramantle is infrastructure your pipelines consume, not a platform that replaces them. You keep your runners, your approvals, and your audit trail, and add a registry and state backend they read from.
What changes in my pipeline to adopt it?
A module source address and a state backend block. Modules point at registry.terramantle.dev instead of Git, and the http state backend points at Terramantle. Adoption is a config change, not a migration project.
So what is the trade-off?
Terramantle does not own execution. If you want a platform to run your applies, manage run queues, and detect drift for you, a TACOS is the right buy and the registry comes bundled. Terramantle is for teams who want to keep execution in their own pipelines.
Next step
Bring this page to your security review.
Terramantle is in beta. If the credential-handling section above is the sticking point in your current IaC evaluation, this is the shape that removes it.
Last reviewed