Terrapod is a free, open-source, self-hosted platform replacement for Terraform Enterprise. This release lets a plan run with a narrower identity than the apply, so code arriving in a pull request need not hold the credentials that change infrastructure.
Highlights
- An optional apply-phase ServiceAccount —
runners.applyServiceAccountgives the apply Job its own Kubernetes ServiceAccount while plan and every other phase keeprunners.serviceAccount. Annotate the two at different cloud roles — IRSA, GCP Workload Identity or Azure Workload Identity — and a speculative plan runs against a read-only role while the apply retains write. Unset, nothing renders at all: no second account, no new key in the runner ConfigMap, and behaviour identical to before. An operator may instead name an account they already manage, in which case the config key renders and the chart creates nothing. - Apply-only variables — a per-variable
apply-onlyflag on workspace variables and variable-set variables. An apply-only variable is withheld from a plan and delivered only to an apply, and a key may be held twice: once plan+apply, once apply-only. SoAWS_ROLE_ARNcan carry a read-only role for plans and a writing role for applies under one name, rather than forcing a second variable name into the configuration. The overlay happens within a precedence tier and never across the chain, so a priority variable set's standard row still outranks a workspace apply-only row — the authority order priority sets exist to establish is unchanged. A key whose only row is apply-only is absent from a plan rather than present-and-empty, because an empty value reaches the engine as a declared variable, which is a different thing. - A conflict an edit can newly create is explained where it happens — clearing the apply-only flag can collide with the standard variable of the same name it coexisted with a moment earlier. That now answers with a message naming the key and which of the two slots is already taken, rendered beside the control rather than only in the page banner, and each row carries an Apply only badge so two copies of a key are distinguishable at a glance — including at phone width, where the category column is not rendered.
The flag is surfaced on every consumer: the API, go-terrapod, both terrapod_variable and terrapod_variable_set_variable provider resources, the terrapod_variable_set MCP tool, and the web UI in all 32 locales.
What this does not do, stated plainly because an operator who believes a plan is harmless stops auditing it: a plan still executes arbitrary code, still needs read access that can enumerate your infrastructure, and still receives every variable not marked apply-only. Terrapod decides which ServiceAccount a Job runs as; whether the role behind it is actually read-only is yours to arrange, and nothing here will warn you if it is not. See security-hardening.md and known-limitations.md.
Upgrade notes
- This release carries one migration (
7a27d4747b9e):apply_onlyis added tovariablesandvariable_set_variablesasNOT NULL DEFAULT false, and both uniqueness constraints are widened to include it. Widening is behaviour-preserving while every row isfalse— the only way to obtain a duplicate key is to set the flag — so an ordinaryhelm upgradeneeds nothing else. - Upgrade the listener before pinning an apply ServiceAccount. The Job spec is built in the listener image, so a listener older than the chart ignores
apply_service_account_nameand silently runs every phase on the default account. Both images default toappVersion, so this only arises from a deliberate pin. - Platform-tool defaults reviewed for the minor:
opa1.21.3,trivy0.76.0,checkov3.3.29. These are pull-through cached rather than baked, so a bump reaches you byhelm upgrade.
Status
Stable — a feature release on the new 1.11 line, cut from v1.10.5. One expand-only migration; no API routes removed and no response attributes removed.
Full Changelog: v1.10.5...v1.11.0