Open-source Kubernetes rightsizing

Trim what your containers don't use.

Kerf sets CPU and memory requests and limits from real usage, prices the difference in dollars, and applies it with guardrails and automatic rollback. You run all of it in your own clusters.

Get started View on GitHub
  • Apache-2.0
  • One Helm chart
  • Starts in audit mode
  • Your data stays in your clusters
The Kerf overview: estimated monthly savings, CPU and memory requested versus recommended versus used, a savings trend per cluster and the top opportunities.

What Kerf does

Many clusters reserve far more CPU and memory than their pods use, and every reserved core is node capacity you pay for. Kerf reads each container's usage from your Prometheus or VictoriaMetrics, recommends requests and limits, and prices the difference per node type. When you allow it, Kerf applies the change and rolls it back if the workload gets unhealthy.

  • Runs in your clusters

    One Helm chart installs the hub, the web UI, the agents and the webhook. Usage data stays in your Prometheus and your PostgreSQL. Agents pull from the hub, so the hub never holds write credentials to a workload cluster.

  • Changes things, carefully

    Choose off, audit or auto-patch per workload and per resource. Guardrails cap each decrease (50% per step by default), freeze windows block changes, and a change followed by OOM kills, restarts or CPU throttling is rolled back.

  • Speaks money

    Savings per workload, namespace and cluster, priced per node type from the AWS price list (on-demand and spot) or your own price table.

  • Knows the workload

    HPA-coupled workloads get their requests and HPA target changed together. JVM containers get heap-aware memory. Single-replica workloads and OnDelete StatefulSets change without downtime.

  • Fits GitOps

    In-place resizes leave the pod template alone, so Argo CD sees no drift. Policies live in the UI or as RightsizingPolicy resources in Git.

  • Shows its working

    Every recommendation explains itself. With the production profile, the CPU request is the 95th percentile of 14 days of usage plus 15% headroom, with a confidence score next to it.

How it works

A hub in one cluster computes recommendations. An agent in each workload cluster decides what to apply under your policies.

Each workload cluster

global.mode: spoke

  • Agent applies, watches, rolls back
  • Admission webhook resources for new pods
  • RightsizingPolicy what may change, and when
  • Your workloads
cAdvisor and kube-state-metrics

Your metrics store

Prometheus, VictoriaMetrics, Thanos, Mimir, AMP

usage history and node costs

Hub cluster

global.mode: hub

  • Hub API and recommender
  • Web UI
  • Pricing price per node type
  • PostgreSQL yours

Each agent pulls recommendations and policies from the hub over HTTPS and reports status back. The hub never connects to a workload cluster.

Kerf's components and data flow. global.mode: all installs everything in one cluster.
  1. Measure. The hub reads each container's CPU and memory usage from your metrics store and computes requests and limits from a percentile of the history plus headroom.
  2. Price. The pricing service prices every node from its instance type and capacity type, so each recommendation carries a monthly saving in dollars.
  3. Apply. The agent resolves the policy for a workload, checks the guardrails, and applies the change with an in-place resize, a rollout, or a deferred patch in a maintenance window.
  4. Watch. The agent watches the workload's health after a change and rolls it back on OOM kills, restarts or CPU throttling. The webhook gives new pods the recommended values.

Features

A web UI for the whole fleet. These screenshots use the UI's built-in sample data.

Opportunities: workloads ranked by estimated monthly savings, with current, recommended and used CPU and memory.

Opportunities

Every workload ranked by estimated monthly savings, with the current, recommended and used values for CPU and memory, the confidence, and bulk actions.

A workload whose CPU change was rolled back by the health watch after its throttling ratio rose above the threshold.

Workload detail

Usage history against requests and the recommendation, the effective policy and where it came from, and a timeline of every change and rollback.

Cluster readiness: metrics, pricing, permission and webhook checks, each with the fix when it fails.

Cluster onboarding

An add-cluster wizard that renders the install command, then readiness checks: Registered → Agent connected → Metrics OK → Ready for audit → Automation ready. A failed check shows the fix.

The policy editor: CPU and memory modes, apply strategy, maintenance windows and guardrails for a rightsizing policy.

Policies and admin

A policy editor with a preview of what changes, defaults, maintenance windows, metrics sources, prices, users and API tokens, an audit log, and a switch that pauses automation for a cluster or the whole fleet.

Also included: Grafana dashboards and Prometheus alerts, a recommendation simulator, high availability for the hub (leader election on PostgreSQL), External Secrets support, NetworkPolicies, and multi-arch images signed with cosign.

How Kerf compares

Kerf takes ideas from the tools below. They are good tools; pick the one that fits.

Kerf compared with other Kubernetes rightsizing tools
Tool License Your data stays in your infrastructure Applies changes In-place resize Rollback on bad health Savings in $ HPA and JVM aware
Kerf Apache-2.0 Yes Yes: policies, maintenance windows Yes Yes Yes Yes: both
Vertical Pod Autoscaler Apache-2.0 Yes Yes: evict and webhook Yes: InPlaceOrRecreate Not found Not found not with an HPA on the same metric
Goldilocks Apache-2.0 Yes through VPA, opt-in through VPA Not found Not found Not found
Robusta KRR MIT Yes: CLI; the UI is SaaS optional webhook, with a Robusta account Not found Not found Not found --allow-hpa
IBM Kubecost commercial, free tier Yes: self-hosted option Kubescaler (alpha) Not found Not found Yes Not found
StormForge commercial metrics go to SaaS Yes Yes Yes Yes Yes: both
PerfectScale commercial, free tier Yes: self-hosted option Yes: maintenance windows Yes Not found Yes JVM; HPA advice
CAST AI commercial SaaS console Yes Yes Not found Yes Yes: both

✓ means documented. – means we did not find it in their public docs on 2026-11-05, which is not proof that it's missing. Every cell, with sources. Corrections are welcome: open an issue.

Use Kerf when

You run several clusters, want rightsizing applied automatically under policies you control, and want it open source and entirely inside your own infrastructure.

Use something else when

  • You have one small cluster, and a VPA in recommendation mode is enough.
  • You need node autoscaling or bin packing: run Karpenter or Cluster Autoscaler next to Kerf.
  • You want a managed SaaS with vendor support.

Quick start

Every cluster starts in audit: Kerf recommends and changes nothing until you turn on auto-patch.

See the UI with a sample fleet

No cluster needed. Requires Node.js 22 and make.

git clone https://github.com/kerf-dev/kerf
cd kerf
make web-dev   # open http://localhost:5173

Install on your clusters

One chart. global.mode picks the role of each cluster.

# the central cluster: hub, web UI, pricing
helm install kerf oci://ghcr.io/kerf-dev/kerf/charts/kerf \
  --version <version> -n kerf --create-namespace \
  -f values-hub.yaml     # global.mode: hub

# each workload cluster: agent, webhook, CRDs
helm install kerf oci://ghcr.io/kerf-dev/kerf/charts/kerf \
  --version <version> -n kerf --create-namespace \
  -f values-spoke.yaml   # global.mode: spoke

The EKS install guide walks through every step, with example values in deploy/examples/eks. The add-cluster wizard prints the full command for each workload cluster.

Requirements: Kubernetes 1.35 (tested; in-place resize is GA there), Prometheus or VictoriaMetrics with cAdvisor and kube-state-metrics (Thanos, Mimir and Amazon Managed Service for Prometheus also work), cert-manager in each workload cluster, and PostgreSQL 12 or later for the hub.

Questions

What is Kubernetes rightsizing?

Setting each container's CPU and memory requests and limits to what it actually uses, plus headroom. Requests decide how many pods fit on a node, so over-requested pods waste nodes you pay for, and under-requested pods get throttled or OOM-killed.

VPA already does this. Why Kerf?

VPA recommends and can apply requests in one cluster. Kerf adds dollars, a fleet UI, per-resource modes, maintenance windows, rollback on bad health and HPA coordination. VPA is a fine choice for one cluster you watch closely.

Automatic changes in production scare me.

Start in audit: nothing changes. Turn on auto-patch per namespace or workload, for CPU first if you like. Every change is in the activity log and can be rolled back from the UI.

Can I use Kerf with the Horizontal Pod Autoscaler?

Yes. When an HPA scales a workload on CPU or memory utilization, Kerf changes the requests and the HPA's utilization target in one change, so the HPA keeps scaling at the same usage as before.

Does Kerf send data anywhere?

No. Kerf reads metrics from your Prometheus-compatible store and keeps its state in your PostgreSQL. The only calls outside your clusters go to the AWS Pricing and EC2 APIs, and only when you choose AWS prices.

Does it work outside EKS?

The recommender, agent and webhook use standard Kubernetes APIs. EKS 1.35 is the tested platform. On other clusters, prices come from a static table instead of the AWS price list; please report what you find.

Is it another thing to run?

One chart. The hub needs PostgreSQL and a Prometheus-compatible endpoint you probably have already.

Is it ready for production?

Kerf is new (0.x). Run it in audit first, then turn on auto-patch for one namespace and watch the activity log. The roadmap lists what comes next.

What does it cost?

Nothing. Kerf is open source under the Apache License 2.0, with no paid tier and no hosted service. You pay for the compute it runs on.

See what your clusters reserve and don't use.

Install Kerf in audit mode. It recommends and prices every workload and changes nothing until you say so.

Get started Read the docs