Kamaji ROI Calculator: See what it saves at your scale
Stop paying for control-plane servers you don't need. Run them as HA pods instead.
The traditional model adds 3 control-plane servers for every new cluster. The hosted model puts all the control planes on one shared cluster, so it barely grows — 3 servers to start, plus 1 more for every 10 clusters. Drag the slider to see the difference at your size.
Start CalculatingHow to calculate your Kamaji ROI
How to calculate ROI
The shared cluster runs Kamaji, an operator that acts like a control-plane factory. Ask for a new cluster and Kamaji spins up its control plane as a set of HA pods, keeps them healthy, and handles upgrades. Each cluster's worker servers connect to their control plane over the network, exactly as they would to dedicated machines.
Management cluster · running Kamaji
3 base nodes + 1 per 10 clusters
ns: cluster-01
ns: cluster-02
Kamaji operator
watches TenantControlPlane CRs
deploys, upgrades & reconciles every hosted control plane
... ns: cluster-03 → cluster-100 as HA pods
Cluster 01 workers
run only your workloads
Cluster 02 workers
run only your workloads
About Kamaji’s ROI
The hardware behind the numbers
Three servers for 100 clusters is not a rounding trick — it is what the workload asks for. Each control plane runs 2 replicas of kube-apiserver, controller-manager and scheduler, with etcd pulled out into shared clusters rather than one per tenant. Memory is the binding constraint, and the spec below is sized so any one of the three servers can fail while the other two carry the whole load.
Commodity 1U bare metal
- CPU
- 1× AMD EPYC 9654 · 96c / 192t
- Memory
- 512 GB DDR5 ECC · 8×64 GB
- Storage
- 4× 1.92 TB enterprise NVMe
- Network
- 2× 25GbE SFP28 bonded + IPMI
- Chassis
- 1U · R6615 / DL325 Gen11 class
shipping SKUs — nothing exotic
Where the capacity goes
- Control planes · 200 pods
- 100 vCPU / 200 GiB
- Shared etcd · 30 × 3 members
- 180 vCPU / 720 GiB
- Platform · CNI, CSI, LB, Kamaji
- 18 vCPU / 36 GiB
- Baseline total
- 298 vCPU / 956 GiB
- Per server, one node down
- 149 vCPU / 478 GiB
against 192 vCPU / 512 GiB on hand
The three-server configuration holds to roughly 106 clusters — 32 shared etcd clusters — where memory runs out before CPU does. Past that the calculator adds servers, which is why the shared side grows at all.
Beyond the hardware savings
Fewer servers is the headline, but the hosted way also makes everyday operations simpler.
- 1
New clusters in minutes
Spinning up a cluster no longer means buying and configuring three servers — the control plane starts as a few pods in minutes.
Days → Minutes
- 2
No more idle servers
Dedicated control-plane servers spend most of their time nearly idle. Sharing servers keeps them busy, so you pay for what you actually use.
Pay for actual use
- 3
Easier upgrades
Upgrading a control plane is a controlled pod update on the shared cluster — repeatable, and easy to roll back if needed.
Easy to roll back
- 4
Everything in one place
Monitoring, backups, and security patches for every control plane happen on one cluster, with one set of tools.
One place to manage
- 5
Fixes itself
If a control-plane pod fails, the shared cluster restarts it automatically — no one gets paged for a dead server at 3 a.m.
Self-healing
- 6
Safer by design
Your apps and the control plane never share servers, and app teams never touch control-plane machines — a cleaner boundary.
Cleaner separation