Dora NodaIn May 2026, the most interesting Terraform challenger you may not have heard of learned Kubernetes. formae — the Pkl-based, agentic IaC platform from Platform Engineering Labs — shipped native K8s support, Helm integration, direct .tfvars compatibility, and a public plugin hub in a single release. Its pitch: one continuously codified source of truth across your entire Kubernetes estate and cloud providers, with no state files to babysit.
That pitch lands differently depending on where you stand. If your fleet is a pile of ClickOps and half-migrated Terraform, a tool that discovers reality and turns it into versioned code sounds like rescue. But if you already run a Cluster-API-managed fleet with GitOps reconciliation, the honest question is sharper: is this a layer you need, or a second reconciler fighting the first one over the same objects? Here is the verdict up front, with the reasoning below.
| Question | Short answer |
|---|---|
| Should formae provision a CAPI fleet's machines? | No — Cluster API controllers already own that loop. |
| Should it be the fleet's system of record? | Possibly — continuous codification of out-of-band changes is the one job nothing else does. |
| Should you migrate Terraform to it today? | Not yet — the license and provider surface need scrutiny first. |
What formae actually shipped in May 2026
formae launched in October 2025 with a deliberately provocative position: sunset Terraform, stop maintaining state files, and let agents keep versioned code in sync with live infrastructure instead. It demoed at KubeCon North America that November, and by February 2026 you could install formae itself onto Kubernetes with a Helm chart. The May 2026 release — announced around May 13–15 and covered across the DevOps press — is the one that moved it from "interesting cloud tool" to "something a Kubernetes platform team has to evaluate":
- Full Kubernetes support, covering vanilla clusters plus managed flavors such as EKS and AKS, so standard K8s resources are managed directly rather than through a Terraform-provider abstraction.
- Native Helm integration, added after early design partners asked the obvious question — "we already use Helm everywhere, can formae work with that?" — so existing charts become first-class inputs instead of wrapped artifacts.
- Direct
.tfvarscompatibility, letting teams reuse their existing Terraform variable files instead of rewriting values to adopt the tool. - A public plugin hub, following the earlier plugin SDK launch, with a build-and-test environment meant to check extension reliability and compatibility across teams.
"We put significant thought and innovation into our Kubernetes support, making it fully consistent with the rest of formae," said co-founder and CEO Pavlo Baron, calling Kubernetes "the last major integration we needed to fully catch up with incumbents decades older than us." The positioning is explicit: formae wants to be the system of record — a single, continuously codified source of truth spanning the Kubernetes estate and the cloud accounts underneath it.
How formae differs from Terraform: four ideas that matter
Press releases say "Terraform killer." The architecture says something more specific. Four ideas separate formae from the push-model tools it wants to replace:
1. Code artifacts extracted from reality, not just applied to it. formae's unit of work is the forma (Latin singular of "form"): a versioned, declarative code artifact describing one resource or a whole stack. Crucially, formas are extracted from live infrastructure as well as applied to it. Point formae at an environment and it discovers what is running and generates the code — no terraform import choreography, no state surgery before the tool becomes useful.
2. Agents own state, not clients. In Terraform and Pulumi, the CLI holds the state file and the state file is the truth the next plan is diffed against — which is why state corruption, locking conflicts, and multi-writer drift are evergreen operational headaches. formae moves state stewardship into always-on agents that observe the live environment, so there is no client-side state file to corrupt, lock, or back up.
3. Drift gets merged, not reverted or ignored. This is the sharpest break. GitOps tools revert out-of-band changes; Terraform flags them at the next plan and asks a human to reconcile. formae's agents detect external changes — a ClickOps fix at 2am, a security tool's adjustment, another IaC tool's apply — and codify them back into the versioned code. Emergency fixes stop being invisible debt that the next apply silently destroys.
4. Co-existence instead of migration-or-nothing. Because discovery is automatic and drift is merged, formae is designed to run alongside existing tools rather than demanding a flag-day migration. That is also the honest reading of the .tfvars compatibility: it lowers the cost of trying formae on a Terraform-shaped estate without rewriting every value file first.
None of this is magic — an agent that merges drift still has to decide, field by field, whether the human or the code wins — but it is a coherent answer to the failure mode every platform team knows: the code says one thing, the console says another, and nobody can prove which one is right.
The three jobs of Kubernetes IaC, mapped onto a CAPI fleet
Pulumi's 2026 survey of the space makes a framing point worth stealing: "Kubernetes IaC" is actually three different jobs. Provisioning (create the cluster and its cloud dependencies) belongs to Terraform, OpenTofu, or Pulumi. Packaging (template and version workloads) belongs to Helm and Kustomize, and continuous reconciliation (keep running state matched to declared state) belongs to Argo CD and Flux.
Tools fail when they blur these jobs; teams fail when they buy two tools for the same job.
Now map those jobs onto a self-hosted, Cluster-API-based fleet like the one behind Bex.co:
- Provisioning machines is owned by Cluster API itself. CAPI providers turn declarative
MachineandClusterobjects into real servers on owned hardware, withMachineHealthCheckremediation and autoscaler pairing handling the lifecycle. There is no cloud API to wrap and no Terraform state to maintain — the Kubernetes API is the state store, with etcd underneath it. - Packaging workloads is owned by Helm charts and Kustomize overlays, versioned in git like everyone else's.
- Continuous reconciliation is owned twice over: CAPI controllers reconcile machine lifecycle, and Argo CD or Flux reconciles workload manifests. Both loops are declarative, level-triggered, and already running.
This is why the "another IaC layer" question bites. A platform that is already GitOps-native does not have formae's core problem — code and reality diverged and nothing noticed — in the places that matter most. The controllers notice continuously; that is what they are for. Any new layer has to earn its place in the gaps between these loops, not on top of them.
The overlap audit: where formae adds versus duplicates
So run the audit job by job. For each thing formae offers, ask: does the CAPI fleet already have this, and what breaks if two systems own it?
| formae capability | CAPI-fleet status | Verdict |
|---|---|---|
| Discover live infra, extract versioned code | Partial — GitOps covers declared workloads, not out-of-band cloud/console changes | Adds value. Nothing else codifies the 2am console fix. |
| Reconcile declared state continuously | Owned — CAPI controllers + Argo CD/Flux already run this loop | Duplicates. A second reconciler over the same objects is a conflict, not a backup. |
| Manage Helm releases as first-class inputs | Owned — Helm/Kustomize via GitOps, versioned in git | Duplicates, unless formae becomes the release path itself. |
.tfvars bridge off Terraform | N/A for fleets that never used Terraform for machines | Adds value only during migration off a Terraform-managed estate. |
| Cross-estate system of record (K8s + cloud accounts in one view) | Missing — CAPI sees machines, GitOps sees workloads, nobody sees both plus the cloud bill side | Adds value. This unified inventory is the genuine gap. |
The duplicate row deserves its failure mode spelled out, because "two reconcilers" sounds abstract until it pages you. Suppose formae's agents and Argo CD both manage the same Deployment. Argo CD's contract is git is truth; revert anything else. formae's contract is reality is truth; codify anything else.
An engineer scales the deployment by hand during an incident. formae dutifully codifies replicas: 6 into its record; Argo CD dutifully reverts it to the git-declared replicas: 3. Each tool behaves correctly according to its own contract, and the system as a whole oscillates. The fix is ownership boundaries — each object reconciled by exactly one loop — but that fix concedes the point: formae's reconciliation is not additive here. Its recording is.
That distinction is the whole answer. As a provisioner, formae is redundant on a CAPI fleet: CAPI already turned machine lifecycle into declarative, continuously reconciled API objects, which is the destination formae is driving toward from the other direction. As a recorder — the layer that notices what happened outside every loop and turns it into versioned, reviewable code — it does a job that CAPI, Helm, and GitOps all leave open. Nobody's controller writes the postmortem entry for the change it didn't make.
Two honest caveats before you pilot it
The license is FSL, not open source as most teams mean it. formae's GitHub repository carries an FSL-1.1-ALv2 badge — the Functional Source License, which converts to Apache 2.0 after a holdback period but restricts competitive use in the meantime. That is source-available, not OSI-approved open source, and the distinction matters for a self-hosting story built on "machines you own, software you can fork." HashiCorp's BSL era taught the industry to read these licenses rather than the headlines. A platform evaluating formae should confirm exactly which uses the FSL functional-use grant covers before building fleet tooling on top of it — and track the conversion date the way you'd track any other dependency sunset.
The project is young and the provider surface is unproven where it matters. formae is less than a year old; the Kubernetes support it would be evaluated on is months old. More concretely for a Hetzner-and-bare-metal fleet: the announced K8s flavors are vanilla, EKS, and AKS, and the cloud story centers on the hyperscalers. Whether formae's discovery and codification handle a CAPH-provisioned fleet — Robot API servers, Cloud firewalls, machines with no cloud-provider API behind them — is an open question no press release answers. A pilot should start with discovery-only mode against a staging fleet and grade the output before granting any agent write access.
Conclusion: recorder, not provisioner
The IaC landscape spent a decade converging on a pattern: declare what you want, let a controller loop close the gap, keep the declaration in git. Cluster API brought that pattern to the machines themselves, which means a CAPI-based platform already lives in the world formae is trying to build — at least for the objects its controllers see.
Evaluate formae for what those controllers don't see. Run it read-only against a real fleet and ask three questions: does its extracted code match reality on the first pass, does it correctly codify a deliberate out-of-band change without mangling the surrounding config, and does its unified inventory show you something your existing dashboards don't? If the answer to all three is yes, you have found your system of record. If any answer is no, you have saved yourself a second reconciler — and the 2am oscillation page that comes with it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
