The KEDA HTTP Add-on scales Kubernetes workloads from real request traffic

Why KEDA core refuses to scale on HTTP

The KEDA HTTP Add-on allows Kubernetes users to automatically scale their HTTP servers up and down, including to and from zero, based on incoming HTTP traffic.

The interesting part is why this is a separate project rather than a scaler inside KEDA. The README gives three reasons KEDA does not include an HTTP-based scaler out of the box.

The concept of an HTTP event is not well defined. KEDA's scalers are described as sources of events, systems that produce precisely measurable events via an API. A message queue depth, a pending job count or a Prometheus metric are all precise. A request is not: it arrives, it is handled, it may be cached, it may be rejected, and how many of those count as work depends on the application.

Second, there is no out-of-the-box single system that can provide an API to measure the current number of incoming HTTP events or requests. The queue depth lives in the broker, the metric lives in the application's Prometheus endpoint, and neither is a general answer to the question.

Third, and this is the one that decides the architecture, the infrastructure required to achieve these measurements is more complex and, in some cases, needs to be integrated into the HTTP routing system in the cluster, for example the ingress controller.

So the design decision was to keep HTTP scaling out of the core and build it as an add-on composed of simple, isolated components with an opinionated way to put them together. The project is often called KEDA-HTTP.

The context around it is worth knowing. This is a Cloud Native Computing Foundation graduated project, the code is Go and Apache 2.0 licensed, the last push was on 2026-10-13, and the tags are v0.16.0 from 2026-09-16, v0.15.0 from 2026-06-15 and v0.14.0 from 2026-04-24.

Beta status, and what that means for your manifests

The README carries a project status callout, and it is unusually precise about what beta means here.

The HTTP Add-on is in beta and actively maintained by the KEDA community, with a v1.0 release planned. It is stable, though minor breaking changes such as removal of deprecated resources or adjustments to deployment manifests and configuration may still occur before v1.0. If you have questions, the project asks you to open a discussion rather than an issue.

So the practical reading is: the code runs and is maintained, and the interface you configure may still move. That is a different risk from a beta that might not work. The breaking changes named are the removal of deprecated resources and adjustments to deployment manifests and configuration, which means the cost of an upgrade is reapplying configuration, not rewriting an integration.

There is also a commercial note in the same callout. For a commercially supported alternative, the README points to the Kedify HTTP Scaler. Naming that is useful context rather than a review of a rival, since it tells you the commercial market for HTTP scaling exists and that the community project is not the only way to get it supported.

The project also runs an adopters list. The README says it is always happy to start listing users who run the HTTP Add-on in production or are evaluating it, with details in `ADOPTERS.md`, and it welcomes pull requests to add new adopters. A list of production users is a more useful signal for an infrastructure add-on than any badge, because the failure modes here are integration specific rather than API specific.

For the code of conduct and contribution path, the README points at the organization-wide CNCF code of conduct and the KEDA contributing guidelines, with `docs/developing.md` for anyone wanting to contribute code.

Three images: operator, interceptor and scaler

The Makefile is where the component structure becomes concrete, and it names three images.

IMAGE_OPERATOR     ?= $(IMAGE_REGISTRY)/$(IMAGE_REPO)/http-add-on-operator
IMAGE_INTERCEPTOR  ?= $(IMAGE_REGISTRY)/$(IMAGE_REPO)/http-add-on-interceptor
IMAGE_SCALER       ?= $(IMAGE_REGISTRY)/$(IMAGE_REPO)/http-add-on-scaler

GIT_COMMIT       ?= $(shell git rev-list -1 HEAD)
GIT_COMMIT_SHORT ?= $(shell git rev-parse --short HEAD)
DATE             ?= $(shell date -u +"%Y-%m-%dT%H:%M:%SZ")

IMAGE_OPERATOR_VERSIONED_TAG     ?= $(IMAGE_OPERATOR):$(VERSION)
IMAGE_INTERCEPTOR_VERSIONED_TAG  ?= $(IMAGE_INTERCEPTOR):$(VERSION)
IMAGE_SCALER_VERSIONED_TAG       ?= $(IMAGE_SCALER):$(VERSION)

IMAGE_OPERATOR_SHA_TAG     ?= $(IMAGE_OPERATOR):$(GIT_COMMIT_SHORT)
IMAGE_INTERCEPTOR_SHA_TAG  ?= $(IMAGE_INTERCEPTOR):$(GIT_COMMIT_SHORT)
IMAGE_SCALER_SHA_TAG       ?= $(IMAGE_SCALER):$(GIT_COMMIT_SHORT)

KO_RELEASE_PLATFORMS ?= linux/amd64,linux/arm64,linux/s390x

The default registry is ghcr.io with the repository kedacore, and each image gets both a version tag and a commit SHA tag. The `VERSION` variable is exported so that ko can use it in the `.ko.yaml` ldflags, which is how the version ends up inside the binary rather than only in the tag.

The build is done with ko rather than a plain Dockerfile, and the default make target is `ko-build`. The release platforms are linux/amd64, linux/arm64 and linux/s390x, so s390x is in the list, which is what you want if you are running IBM Z hardware.

The repository layout matches the three components: an `operator/` directory, an `interceptor/` directory and a `scaler/` directory, with `pkg/` for shared code and `cli/`, `config/`, `docs/`, `examples/`, `hack/` and `test/` around them. The interceptor is the piece that sits in the HTTP routing path, which is the third of KEDA's three reasons for keeping HTTP scaling out of the core, and the scaler is the piece that reads the measurement and reports it to KEDA.

There are two example directories, `examples/networkpolicy/` and `examples/xkcd/`, which is a useful hint about the shape of the configuration. The network policy example is the one to read if you plan to run this in a cluster with a default-deny policy, since the interceptor has to be reachable from the ingress controller.

Helm charts and the versions they pin

The deployment side is Helm, and the Makefile pins the chart versions it expects, with a renovate comment above each one showing the datasource and the chart repository:

# renovate: datasource=helm depName=cert-manager registryUrl=https://charts.jetstack.io
CERT_MANAGER_VERSION ?= v1.21.2
# renovate: datasource=helm depName=jaeger registryUrl=https://jaegertracing.github.io/helm-charts
JAEGER_VERSION ?= 4.14.0
# renovate: datasource=helm depName=keda registryUrl=https://kedacore.github.io/charts
KEDA_VERSION ?= 2.21.0
# renovate: datasource=helm depName=opentelemetry-collector registryUrl=https://open-telemetry.github.io/opentelemetry-helm-charts
OTEL_COLLECTOR_VERSION ?= 0.173.1

HELM_RETRIES ?= 3

Four dependencies are pinned: cert-manager at v1.21.2, Jaeger at 4.14.0, KEDA itself at 2.21.0 and the OpenTelemetry collector at 0.173.1. The renovate comments are the mechanism that keeps them current, since they name the chart repository and the dependency name for the automated updater to find.

The KEDA version matters most, because the add-on is an extension of KEDA and a mismatch between the add-on and the core can show up as custom resource definitions that the operator cannot reconcile. Pinning to the same KEDA release the add-on was built against is the safe default.

cert-manager being required is worth noting because it is the component that issues certificates for the TLS between the interceptor and the scaler, and for the add-on's own serving certificates. A cluster without cert-manager needs it installed first, which is one more moving part than a self-contained add-on would suggest.

The presence of Jaeger and the OpenTelemetry collector is also a design statement: the add-on is expected to be observable in the same way as the rest of your cluster, and the Go dependency list confirms it with the full OpenTelemetry SDK, the OTLP exporters over HTTP, gRPC and protobuf, and the Prometheus metric exporter.

The `HELM_RETRIES ?= 3` setting is a small operational touch that tells you the deployment script expects transient failures from the chart repositories.

The Go dependency set tells you what it measures

The `go.mod` is worth reading because the dependency choices describe the implementation.

The module is `github.com/kedacore/http-add-on` and it requires Go 1.26.0. The core dependency is `github.com/kedacore/keda/v2` at v2.21.0, so the add-on links against the KEDA API directly rather than talking to it over the cluster API alone. Kubernetes client libraries are at v0.37.1 for api, apimachinery and client-go, and `sigs.k8s.io/controller-runtime` at v0.25.1, which is the standard framework for a Kubernetes operator.

Two dependencies point at the mechanism. `github.com/coder/websocket` at v1.8.15 is a WebSocket library, and it is the right clue for how the interceptor reports measurements to the scaler over a long-lived connection rather than by polling. `github.com/tsenart/vegeta/v12` at v12.13.0 is a load testing library, which is the component used to drive traffic at the service for testing the scaler behaviour.

The testing stack is also complete. Ginkgo and Gomega for the end to end suite, `sigs.k8s.io/e2e-framework` at v0.7.0 for driving a real cluster in tests, testify and go-cmp for unit assertions, and gotestsum as the test runner, listed under the `tool` directive alongside protoc-gen-go, protoc-gen-go-grpc and controller-gen, which are the code generation tools for the protobuf definitions and the CRD manifests. The `buf.yaml` and `buf.gen.yaml` files at the root are the configuration for that protobuf generation.

Observability and configuration round out the list. The OpenTelemetry packages cover traces, metrics and the HTTP and gRPC instrumentation, the Prometheus client is there for the add-on's own metrics, `github.com/caarlos0/env/v11` at v11.4.1 is a library for parsing configuration from environment variables, and `github.com/hashicorp/go-immutable-radix/v2` is the immutable map implementation.

The `scaler/` and `interceptor/` directories in the repository layout are where these libraries are put to work, and the `Makefile` sets `SHELL = /bin/bash` with `.SHELLFLAGS = -eo pipefail -c` so that a failing step in a recipe stops the build rather than being swallowed by a pipeline.

Installing it, and where the answer actually lives

The README deliberately keeps installation out of itself. For getting started, installation, architecture and configuration, it points to the KEDA HTTP Add-on documentation at keda.sh/http-add-on/latest/, and it does the same for the per-version site, with the documentation site being the project's homepage.

That is a defensible choice for a Kubernetes component, because the install is a Helm release with several chart dependencies and the exact values file matters. But it does mean the repository README alone is not enough to get started, and any guide claiming otherwise is out of date.

What the repository does give you is the configuration surface. The `config/` directory holds the CRD and the Kubernetes manifests, `examples/` holds the two worked examples, `cli/` holds a command line component, and `hack/` holds development helper scripts. There is also a `.devcontainer/` directory for a containerised development environment, a `.golangci.yml` for the linter configuration, a `.pre-commit-config.yaml`, and a `lychee.toml` for link checking, which is a small sign that the project treats broken documentation links as a defect.

For contributors there is more: `docs/developing.md` is the guide for contributing code, `CONTRIBUTING.md` holds the KEDA community guidelines this project follows, `RELEASE-PROCESS.md` describes how releases are cut, and `SECURITY.md` covers vulnerability reporting. The `CHANGELOG.md` at the root is where you look to see whether a change you depend on has moved in a version.

So the practical path is: read the docs site for the install, use the repository for the CRDs, the examples and the chart source, and check the changelog when you upgrade a beta.

Where an interceptor-based approach is the wrong shape

There is a real cost to this design that the README states plainly and that you should weigh before adopting it.

The interceptor sits in the HTTP request path. The README says the infrastructure required to measure incoming HTTP traffic is more complex than a queue depth metric, and in some cases needs to be integrated into the HTTP routing system in the cluster, for example the ingress controller. That means the add-on is only as good as your ingress's willingness to be configured, and it means a new component is now on the critical path of every request your service receives.

For teams that already run a mesh or a gateway they control, that is manageable. For teams on a managed ingress they cannot reconfigure, or on a platform where the routing layer is out of your hands, the add-on may simply not fit, and no amount of configuration fixes it.

The alternative approach is the one KEDA already offers, and it is worth naming precisely. Every other KEDA scaler reads a signal that already exists somewhere else, a queue depth, a Prometheus metric on the application, a cloud provider API. If your HTTP service already exports request rate and error rate as Prometheus metrics, a Prometheus scaler against those metrics gives you scaling on request traffic with no interceptor, no extra hop and no change to the ingress. The difference in approach is that the add-on measures at the edge and knows about individual requests, while the Prometheus route measures the application's own view of them, and the second is easier to run but slightly less faithful, since it only sees requests that reached the application.

For the from-zero case, KEDA's scaling to zero still needs a trigger, and HTTP traffic is the common one, which is why this add-on exists. But a service that never scales to zero can often use a queue scaler or a metric scaler and avoid the interceptor entirely.

There is also the operational cost of a new controller in your cluster and a new webhook and certificate in your trust chain, which is real but modest for a team already running Kubernetes operators.

Editorial conclusion

Adopt the KEDA HTTP Add-on when you need to scale a Kubernetes HTTP workload from real request rates, including down to zero, and you can accept adding an interceptor into your ingress path. Do not adopt it if you need a stable v1 API contract, since the project is in beta and says minor breaking changes may still occur before v1.0. Verify first that your ingress can be configured to route through the interceptor, that the scaler can reach your application's metrics endpoint, that the KEDA chart version you pair with it matches the `kedacore/keda` version the Makefile pins, and that cert-manager is installed, since the interceptor's TLS handling depends on it.

Frequently asked questions

Official sources

1. kedacore/http-add-on on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases