raw

A variant of Kubernetes Cost Optimizer.

View the interactive variant page →

Kubernetes Cost Optimizer

Part of the worlds-biggest-software-project initiative.

An open, self-hosted Kubernetes cost optimiser: cost allocation you can defend, rightsizing advice you can argue with, and — only if you switch it on, only where you say, and only within limits you set — changes it will make for you.

A cost tool is an instrument of argument between teams. A number it cannot account for loses that argument and takes the product's credibility with it. So every figure this product shows carries the rate that priced it, where that rate came from, the date it was current, and how shared cost was divided — beside the figure, not behind it.

New here? Start with user-docs/getting-started.md.


What it does

Divides the bill. What a cluster costs, split between namespaces, workloads, pods, labels and services, with two things kept separate that most tools bury:

  • Idle — capacity paid for that nobody requested. Reported against the node pool that holds it, never spread quietly across other teams' workloads.
  • Shared — control plane, load balancers and the namespaces you designate, divided in proportion to what each team used, with the method stated.

Allocated plus idle plus shared equals the total for the same period. When it does not, the product says so on screen rather than adjusting a part to make the sum work.

Says what to change. What each workload reserves, what it used, what it should ask for, what that saves a month, and how confident that is — with the reason when it is not. Including INCREASES: a workload being throttled or restarted needs more, and a tool that only reduces eventually causes an outage.

Warns before the bill arrives. Budgets with a projection while there is still time to act, and detection of spending that has changed shape — naming the namespace, the size, when it started and which workloads account for most of it.

Can make the change, within limits. Off by default and off on a fresh install. Turning it on is explicit, for a named namespace or label selector, bounded by how far one change may go, how many workloads may be disturbed at once, and how long before the same one is touched again. Every change and every refusal is recorded, and every change can be undone from that record alone.

Fits the tools you already have. The same figures, with the same provenance, through a documented interface, a monitoring export, a bulk export in the open FinOps format, an interface for AI assistants, and a cost estimate you can run in a code review.


Why it exists

The open tools stop at monitoring or advice; none of them will make the change. The commercial ones that will make the change want broad permissions on your cluster and a percentage of what they save you, which grows precisely as your bill does. Pricing at the top end runs into thousands per cluster per month, and multi-cluster reporting is often behind that tier.

And nearly all of them assume a cloud billing account. On a private cluster, or during the weeks before anybody wires the billing export up, they have nothing to say. This one works from a rate card you type in, labels every figure derived from it as an estimate, and relabels them the moment real billed data arrives.

The critique of the commercial tools is that they demand broad cluster permissions and act on their own. A product that repeats that while calling itself the open alternative has no reason to exist. So: the collector is installed read-only by default, enforcement is off, scope is explicit, and the permission it asks for when you do switch it on is exactly one verb.


How it is built

One Go module. One image, holding three programs that differ only by which is started: the server, the in-cluster collector, and an operator's command-line tool. The interface is React, built to static files and served by the server, so there is no second runtime in the image.

Storage is plain PostgreSQL 16 and nothing else — no TimescaleDB, no extension of any kind. Time series live in native partitions with scheduled rollups in three tiers: individual samples for a fortnight, hour figures for ninety days, day figures for thirteen months. Retention is enforced by dropping a partition rather than deleting rows.

The job queue is in PostgreSQL too, so there is no Redis.

Prometheus is optional. It is supported as a source of usage figures and as an export target, and it is never required: the default source is the metrics interface every conformant cluster already has. Prometheus's one real advantage is that it can answer about the past, so a collector returning after an outage can fill the gap in rather than leave it permanent.

Cloud billing is read from AWS, GCP and Azure where you connect an account. Until you do, figures come from the rate card and say so.

(Earlier drafts of this page described TimescaleDB and Prometheus as dependencies. They were research-stage notes and are not what was built. The research documents under /initial-research are left as they were.)

The shape of the repository

wbsp.yaml, wbsp.Docker    the platform manifest and the image definition
target/                   all the application code
  api/                    the interface description — the source of truth
  cmd/                    the three programs
  internal/               the domain: allocation, recommendations, enforcement, …
  agent/                  what runs inside an observed cluster
  migrations/             versioned schema changes, carried inside the binary
  web/                    the interface
  deploy/helm/            two charts: the collector, and self-hosting the whole thing
user-docs/                written for people with no access to the platform
docs/                     internal notes
initial-research/         research, left as research

Running it

wbsp deploy --destination dev    # a database
cd target
make release                     # brings an empty database to a working state
make demo-seed DESTINATION=dev   # optional: a year of authored example history
make run

Nothing is sourced in between. Each command reads exactly one settings file — the one belonging to the installation named by DESTINATION, dev by default — and asks the platform for that installation's database values as it runs.

The first screen works immediately. There is no setup step between installing and using it, and no first-run wizard: the release step creates the rows a first person needs, not just the schema.

Self-hosting outside the platform uses the chart in target/deploy/helm/kco; the collector goes into each observed cluster with target/deploy/helm/kco-agent.

Full instructions: user-docs/getting-started.md. Commands: user-docs/useful-commands.md.


How it is tested

The money arithmetic is checked against hand-computed answers for the cases where a plausible-looking wrong answer comes from: a pod that started or stopped part way through, a machine that joined or left, a workload with no usage data, a period during which the price changed. The safety limits are tested by proving an out-of-bounds change is REFUSED and the refusal recorded — not merely that an in-bounds change is applied, because a limit that never fires and a limit that was never connected look identical from outside.

Database work runs against a real PostgreSQL. The interface is checked in a real browser for accessibility with zero violations permitted, and again with colour removed. A demonstration is checked by a network recorder that fails if anything outside the container is contacted.

Details, and every individual test by name: user-docs/testing.md.


Who it is for

Platform engineering teams, FinOps practitioners and infrastructure leaders running Kubernetes at a scale where the bill has become somebody's problem — and who would rather host the tool themselves than hand the question to a service that charges a share of the answer.


Contributing

Contributions from developers, domain experts and users are welcome. See CONTRIBUTING.md.

Everything here is original work or used under a compatible licence. Open specifications — the OpenCost data model, the FinOps open cost format, OpenAPI, the Model Context Protocol, the Kubernetes interfaces — are implemented from their public specifications. Competitors' implementations, documentation and proprietary material are not copied or adapted. If you are unsure whether something is safe to contribute, open an issue and ask first.


Licence

Not yet chosen. Until it is, every dependency added is checked for a permissive licence, and anything copyleft needs a recorded decision first.