The authoritative model Terraform made famous has always been a poor fit for teams just trying to automate a little infra. The state file is only its most visible cost. Give up the model and three questions decide the tool: how the truth is represented, where it lives, and what lifecycle runs around it. ConfigHub and formae are already past it, and chant answers the same three again.

  • Representation. ConfigHub makes the truth data in a store. formae makes it Pkl. chant makes it typed TypeScript that is the spec itself.
  • Location. ConfigHub puts the truth in a database. formae pushes it into the source code and reconciles the cloud back to it. chant leaves it in the live system, where it already is.
  • Lifecycle. ConfigHub builds one around its store. formae builds one that pulls reality into code. chant hands the lifecycle to you, dialed per environment.
  • Ownership. Terraform ties it to state. ConfigHub delegates it to live markers in ArgoCD and Crossplane, which is right. chant reads it straight off the resource, no store in the loop.
  • Verdict. Three tools past the authoritative model, and one that also refuses to own you: typed source you already write, truth left live, artifacts that outlive the tool.

ConfigHub owns all three

ConfigHub replaces the file with a database, and the database is the truth. You author in it through an API. It actuates from it. Brian Grant is right that configuration is data and that Git is a poor place to keep it, and the product follows honestly from that.

The representation is spec-native on both sides, and that is worth being exact about. ConfigHub holds KRM, the real spec, as data. chant holds the same spec as typed source. Neither abstracts over it. The split is where the spec lives and how you touch it: records in a store you edit through tools, or typed source you author and read in an editor.

And look at what you signed. The store is your authoring surface, your source of truth, and your control plane at once. Three kinds of lock-in wearing one login.

Ownership is not state

Every deploy tool answers two questions: what is true, and what is mine to delete. The trap is deriving the second from the first.

Terraform walked into it. In the state file a resource is yours because it sits in the file. Drop it and the file authorizes the delete. State and ownership are the same record.

ConfigHub does not make that mistake. Ownership and pruning ride the actuators, ArgoCD and Flux, or Crossplane, ACK, and Config Connector for cloud resources, and those answer “is this mine” from live markers on the resource, not from the store. That is the right design. What stays true is narrower: the store is the desired-state authority. It decides what should exist, and where pruning is on, absence from the store is what the actuators enact.

chant answers ownership the same way those actuators do, from a live marker on the resource, and answers existence from the source. A delete needs both, owned and undeclared. The difference is that there is no desired-state store in the loop. The plan is computed against the live system.

ConfigHub avoided the conflation. It kept the database.

formae gets the truth right, and the wrong language

formae drops the file and keeps the source code as the truth. It reconciles out-of-band changes back into code instead of fighting them. On the calls that matter, formae and chant agree, and the inversion of truth to source is a fine choice.

Then it hands you Pkl. Pkl is a real config language, typed and deterministic, but it is not better than TypeScript. It just looks less like JavaScript. Its one edge is value constraints in the type: a port that refuses anything outside 1 to 65535 before you can save. chant answers that in semantic lint, and the lint reaches farther than Pkl’s constraints do, because it checks meaning across resources, not bounds on a single field.

Both of them require a database

Vendors love to indict Terraform state as a database crammed into a flat file, then sell you a real one as the cure. The cure is the disease.

ConfigHub keeps the truth in a database. formae requires one too. Either way you are running a server before your first resource ships.

The truth already exists in the live system. A second copy you must keep correct and current is the state file’s burden again, in nicer clothes. chant needs none of it. State, when there is any, lives in git, and a database is something you add at scale as an index, never a dependency.

TypeScript is the spec with types on it

A JSON document is almost already a TypeScript object. Same nesting, same values, the keys just lose their quotes. chant leans all the way in. BucketEncryption in your file is BucketEncryption in the template. What you author is what ships, with no second language pointed at the spec and no store between you and it.

And you are about to hand this to agents. They write TypeScript fluently and Pkl by guessing. When the machine authors the source, you want the surface it already speaks.

chant owns none of you

Score the three questions. Truth stays in the live system, not a store chant hosts. The lifecycle is yours: hand the native artifact to your pipeline, or run chant’s own durable Ops, dialed per environment from observe to apply. The authoring surface is TypeScript you already write, and the output keeps working the day you stop using chant.

ConfigHub owns the truth and the lifecycle. formae owns the lifecycle and a language you had to learn first. chant owns none of it. That is the case, and it is why chant is better.

Read more

Update: an earlier version said ConfigHub abstracts over the spec and derives ownership from state. Both were wrong. ConfigHub holds KRM as data, and ownership and pruning ride live markers in ArgoCD, Flux, and Crossplane. Corrected above, with thanks to Brian Grant for the pushback. The database point stands.