Last time I built a container vulnerability scanner on ConfigHub by domain-swapping Brian Grant’s RBAC Manager. This post does it again, but the swap is off the scanner this time. I built a Cost Estimator, and most of what made the CVE tool was already the right shape. I kept the shape and changed the meaning.

For most of the build, that’s what it was. The cost database dropped in where the CVE database had been. The estimator dropped in where the scanner had been. The gate that used to block a CRITICAL image now blocks an over-budget workload instead.

Cost estimation use case

This time, the ask was simple to state:

“Show me what every workload costs, across every cluster, and block the ones that blow their budget from shipping.”

This time the approach is different, because a CVE is a fact and a cost is a function.

I’d like to repeat about this a bit: on ConfigHub, the inventory, the state, the validator, and the API are already done — the same way they were done for the scanner. What’s left is the part specific to cost, and cost is where it diverges. There’s no “the cost” sitting in the image or the registry to go fetch. A cost is a function of the Unit’s own fields: the CPU and memory each container requests, times the replica count, times a rate.

A cost is continuous, predictable, and diffable. You can compute the cost of a config that hasn’t been applied yet. And if you can price one version of a config, you can put an exact number on a change.

We use the same query pattern to pull the resource requests we want to compute cost from:

# every workload that declares resource requests, fleet-wide
cub unit list --space "*" \
--where-data "spec.template.spec.containers.*.resources.requests.|cpu != ''"

“Stop the over-budget ones from shipping” is the same story as the scanner: a Trigger attaches an Apply Gate when a Unit’s data fails a check. And “where do we store the estimate?” has the same answer the scan result did: on the Unit, as data.

You might be wondering why don’t we just use Git. Read Jesper’s article on this to understand more on the reason why Git is not great for being config storage.

That’s the Config-as-Data idea again. When config, policy, and the verdict are all data, the tool needs no backend of its own. It’s a view over ConfigHub plus some domain logic — here, a price book and a cost model.

The estimator reads a workload’s requests and multiplies through — replicas, storage from the volume claims, load balancers counted off a Service of type LoadBalancer — then writes a budget verdict back onto the Unit. The signal the gate reads, budget-status, stays a flat OK/WARN/OVER annotation so the Trigger can match it as a plain string.

Everything else — the line items, a spot what-if, provenance, the diff — rides along in one base64 estimate blob. A within-budget Trigger gates anything marked OVER — and it catches it about as far left as a check can run, before the Unit ever reaches a cluster, because the gate is a check on data, not an admission controller.

We didn’t reinvent cloud pricing; we modeled it on the real thing. The cost DB is a single SQLite file with a schema shaped after OpenCost/KubeCost)’s CustomPricing: per-{provider, region, resource} rates for CPU, RAM, GPU and storage, on-demand and spot, plus network-egress and load-balancer rates, an instance catalog for marginal-rate node normalization, and the per-environment budgets the guardrail gates on.

Because the estimate is computed from config, and config is versioned, you can ask what a workload costs and, just as easily, what a change to it would cost.

That’s the shift-left idea behind Infracost on a Terraform pull request, or kubectl cost predict on a spec. The difference is that those tools have to manufacture a baseline to diff against: Infracost stashes a JSON snapshot of main, and KubeCost reads the cloud bill after the money is spent. On ConfigHub the baseline isn’t manufactured, because the previous revision is the baseline. Config, estimate, and verdict are the same versioned object, so the diff is exact and lands before apply. Re-cost the previous revision and subtract.

Benefit of storing rendered configs

This is also where it parts ways with the config-as-code formats — Helm, Kustomize, cdk8s, CUE. None of them keep the rendered config anywhere; the YAML exists for about as long as it takes to pipe it at a cluster. So an analysis like this has to pick one of two shapes:

  1. Render one app at a time in CI, on the change, and feed the output to the tool — you get the pre-apply number, but no fleet-wide view, or

  2. Read the live clusters — you get the fleet-wide view, but only after the config is running, never before.

You can do both, but that’s two pipelines and the work to join them. ConfigHub stores the rendered config as versioned data, so one query answers both questions:

  • what the whole fleet costs now, and

  • what a not-yet-applied change would cost,

without rendering anything or scraping a cluster.

Each revision keeps its cost estimation as a base64-encoded blob annotation.

ConfigHub SDK is extensible

One thing we changed on purpose: the client. ConfigHub’s SDK ships the OpenAPI spec, so the API client isn’t something you have to inherit — you generate it from the spec, in whatever shape suits the tool. The scanner and the RBAC manager generated an RTK-Query client and leaned on a Redux store because it focused on UI display. The estimator is mostly reads with a handful of writes, so we generated a smaller openapi-fetch client from the same spec: fewer moving parts, still fully typed against the contract. Same endpoints, same types, same auth, different client. When the platform hands you a spec instead of one blessed SDK, you build the surface your tool actually needs.

Takeaway

With AI coding agents, the bigger point I want to emphasize here is that ConfigHub is a platform you can build on easily and quickly. Standing up an internal tool like this is genuinely easy now — but only if the layer underneath is right. What you need is a config store that’s versioned and exposes a real API. That’s what ConfigHub is.

So build apps. Point your favorite AI agent at the ConfigHub SDK and examples, and see what falls out. Try ConfigHub, and see how it could transform the way you build your next internal platform tools.

Questions or feedback? Email us at hello@confighub.com.