by Jan Wozniak

April 07, 2026

Introduction

Running a single KEDA operator per cluster works well until you need isolation between teams, customers, or environments that share the same cluster.

Maybe you’re a platform team offering autoscaling as a service to internal teams. Maybe you host workloads for multiple customers and a noisy neighbor’s misconfigured ScaledObject shouldn’t affect anyone else. Or maybe you simply need different KEDA versions or configurations for different parts of your cluster.

Today we’re introducing Multitenant KEDA - a new capability that lets you run multiple isolated KEDA operators inside a single Kubernetes cluster, each responsible for scaling workloads in its own set of namespaces. A single shared metrics adapter routes HPA requests to the correct operator automatically, with full mTLS isolation between tenants.

The Problem: Shared KEDA, Shared Risk

In a standard KEDA deployment, one operator handles all ScaledObjects across the cluster. This creates a few challenges for platform teams:

• Blast radius - a broken or excessively frequent trigger in one namespace can starve the operator’s reconcile loop, delaying scaling for everyone else
• Configuration coupling - operator-level settings (polling interval, log level, resource limits) are global, so one team’s requirements may conflict with another’s
• Upgrade risk - upgrading KEDA means upgrading it for every tenant at once, with no way to canary or roll back per tenant
• Noisy neighbor metrics - a single metrics adapter serving all HPAs means one tenant’s slow external metric source can add latency to another tenant’s scaling decisions

Multitenant KEDA solves these problems by giving each tenant its own KEDA operator while keeping the operational overhead of a single cluster.

Architecture

Multitenant KEDA introduces three components:

1. Tenant KEDA operators - each runs in the keda namespace but watches only its assigned target namespace(s). They are fully independent: separate deployments, separate TLS certificates, separate reconcile loops.

2. Shared metrics adapter - a single keda-operator-metrics-apiserver that the Kubernetes API server calls for external metrics. It routes each HPA’s metric request to the correct tenant operator based on the ScaledObject’s namespace.

3. Kedify agent is responsible for setting up the multitenancy internal configuration.

Under the hood, the flow looks like this:

1. Each tenant KEDA operator registers itself by creating a ConfigMap labeled kedify.io/tenant-registration: "true"
2. The kedify-agent discovers these ConfigMaps, reads TLS certs from each tenant’s secret, and syncs everything into a single configuration secret
3. The metrics adapter watches this secret, builds a namespace-to-tenant routing table, and establishes mTLS gRPC connections to each operator
4. When an HPA asks for metrics from namespace foo, the adapter routes the request to the operator watching foo

Each tenant operator only sees ScaledObjects in its own namespace. The mTLS certificates are unique per tenant, so even the gRPC transport is isolated.

Autoscale with confidence, even in shared clusters.

Try multitenant KEDA with Kedify today.

Get Started

Scaling KEDA with Operator Sharding

A single KEDA operator works well for small to mid-size clusters. But as the number of ScaledObjects grows into the hundreds or thousands, the operator’s single reconcile loop becomes the bottleneck. Each ScaledObject means another set of metric queries, HPA updates, and status writes, all serialized through one controller. At around 1000+ ScaledObjects, you may start to see increased reconcile latency, delayed scaling decisions and impact of rate-limiting.

Multitenant KEDA addresses this directly: instead of one operator handling every ScaledObject in the cluster, you shard the work across multiple operators, each watching a subset of namespaces. If you have 3000 ScaledObjects spread across 30 namespaces, you might run three operators each watching 10 namespaces, cutting the per-operator load by a third. Or 30 operators, each handling their dedicated namespace. You can deploy multiple keda-operators in a single namespace, keda-operator per namespace, or any combination of both deployment topologies.

This is also where tenant isolation becomes a practical benefit rather than just an organizational one. A tenant running a trigger that makes slow HTTP calls to an external API won’t delay scaling for tenants served by a different operator. Each operator maintains its own reconcile queue, metric connections, and goroutine pool.

You enable this by installing one KEDA operator in default mode and one per tenant in tenant mode (see Getting Started below). On its own, the default operator behaves identically to a standard single-tenant KEDA deployment; the difference is that it can now coordinate with additional tenant operators.

mTLS Certificate Management

Each tenant KEDA operator generates its own TLS certificate pair (managed by KEDA’s built-in cert rotation). The kedify-agent reads these certificates and distributes them to the metrics adapter, which uses them to authenticate gRPC connections to each operator.

Certificate rotation is handled automatically:

• The agent periodically checks for certificate changes (hash-based comparison)
• Updated certificates are synced to the shared configuration secret
• The metrics adapter detects the secret change via filesystem watch and reloads TLS credentials without a restart

This means certificate rotation is seamless - no downtime, no manual intervention, no coordinated rollouts.

Getting Started

Setup involves deploying the tenant operators via Helm. Here’s a walkthrough for a cluster with two tenants (foo and bar) plus the default tenant. Add the Kedify chart repo first:

helm repo add kedifykeda https://kedify.github.io/charts
helm repo update

1. Install the kedify-agent with multitenancy enabled:

helm upgrade --install kedify-agent kedifykeda/kedify-agent \
  --namespace keda --create-namespace \
  --set agent.features.multitenantKEDAEnabled=true \
  --set agent.orgId="****" \
  --set agent.apiKey="****"

The agent watches for tenant registration ConfigMaps and syncs TLS certificates to the metrics adapter.

2. Install the default KEDA operator in multitenant mode:

helm upgrade --install keda kedifykeda/keda --version v2.20.1-4 \
  --namespace keda --create-namespace \
  --set kedify.multitenant.mode=default \
  --set watchNamespace=keda

3. Deploy a KEDA operator for each tenant:

In tenant mode the chart turns off the shared singletons (CRDs, metrics server, webhooks) automatically and derives the operator, service account, and certificate names from the release name, so each tenant only needs its mode and watched namespace:

helm upgrade --install foo kedifykeda/keda --version v2.20.1-4 \
  --namespace keda \
  --set kedify.multitenant.mode=tenant \
  --set watchNamespace=foo

Each tenant operator runs as a separate deployment in the keda namespace but only reconciles ScaledObjects in its target namespace. Repeat for each additional tenant with a unique release name and watchNamespace.

4. Create ScaledObjects in tenant namespaces as usual, they’ll be picked up by the correct operator automatically.

What’s Next

If you’re running a platform where multiple teams or customers share a Kubernetes cluster and need isolated autoscaling, we’d love to hear about your use case.

Try It Today

• Please book a demo to walk through a multitenant setup tailored to your environment.
• Check the multitenant KEDA documentation for detailed configuration and architecture reference.

Built by the core maintainers of KEDA. Designed for teams that scale with confidence.