Resource Footprint
This page gives a rough idea of how much CPU and memory the Kedify stack uses, so you can size a cluster before installing. Treat the figures as a starting point and measure your own workload for precise capacity planning.
What runs
Section titled “What runs”A standard install (the kedify-agent umbrella chart with HTTP scaling enabled) deploys:
- kedify-agent: connects the cluster to the Kedify platform and drives autowiring.
- KEDA: the operator, metrics API server, and admission webhook.
- HTTP add-on: the interceptor (Envoy xDS control plane) and the external scaler.
- OTel add-on: the operator and scaler.
- Kedify Proxy: an Envoy data plane, autowired per scaled Service (cluster-wide or per namespace).
Footprint at rest
Section titled “Footprint at rest”CPU at rest is small across the whole stack. Memory is the cost that grows with the number of scaled applications. The table below shows total stack memory at rest for a given number of ScaledObjects, in MiB. The Kedify Agent figure reflects normal online operation.
| ScaledObjects | Kedify Proxy | HTTP interceptor | Kedify Agent | KEDA + OTel + scaler (fixed) | Whole stack memory |
|---|---|---|---|---|---|
| 10 | 20 | 80 | 75 | 150 | 325 |
| 50 | 25 | 115 | 75 | 150 | 365 |
| 100 | 25 | 135 | 75 | 150 | 385 |
| 200 | 35 | 165 | 75 | 160 | 435 |
| 300 | 45 | 175 | 75 | 165 | 460 |
At rest the whole stack draws well under 0.1 vCPU total, even at 300 objects.
What grows with app count is memory, and mostly in the HTTP interceptor, which holds the configuration for every HTTPScaledObject. The Kedify Proxy stays small (around 20 to 45 MiB from 10 to 300 objects) because it only receives a compact Envoy configuration from the interceptor, not the full object set. KEDA, the OTel add-on, the external scaler, the admission webhook, and the agent stay effectively flat regardless of app count.
Kedify Proxy data plane (traffic cost)
Section titled “Kedify Proxy data plane (traffic cost)”Proxy CPU scales with request rate; memory stays flat.
| Requests per second | Proxy CPU | Proxy memory | Avg latency |
|---|---|---|---|
| 500 | 20m | 35Mi | 4.0 ms |
| 1,000 | 70m | 45Mi | 4.1 ms |
| 4,000 | 230m | 45Mi | 4.0 ms |
| 20,000 | ~1 core | 50Mi | 6.9 ms |
That is roughly 50 millicores of CPU per 1,000 requests per second, close to linear, so one Envoy core handles about 20,000 requests per second of small requests. The default proxy CPU limit (500m) is enough for roughly 10,000 requests per second per replica. Size proxy replicas and limits by your peak request rate. See Kedify Proxy Performance Tuning for tuning options.
Rule of thumb
Section titled “Rule of thumb”For 300 scaled applications, plan for about 0.5 vCPU and 0.5 GiB of memory for the whole Kedify control plane, plus data-plane proxy CPU sized by peak traffic at roughly 50 millicores per 1,000 requests per second. The control plane idles well under 0.1 vCPU; the extra CPU headroom covers short bursts when many applications are created or changed at once. The one component that grows noticeably with your application count is the HTTP interceptor, for its per-object memory. Everything else is close to fixed overhead.