This page covers deploying Feast on Kubernetes, including the Feast Operator and feature servers.

Kubernetes is a common target environment for running Feast in production. You can use Kubernetes to:

1. Run Feast feature servers for online feature retrieval.
2. Run scheduled and ad-hoc jobs (e.g. materialization jobs) as Kubernetes Jobs.
3. Operate Feast components using Kubernetes-native primitives.

To deploy Feast components on Kubernetes, use the included feast-operator.

For first-time Operator users, it may be a good exercise to try the Feast Operator Quickstart. The quickstart demonstrates some of the Operator's built-in features, e.g. git repos, feast apply jobs, etc.

{% embed url="https://www.youtube.com/playlist?list=PLPzVNzik7rsAN-amQLZckd0so3cIr7blX" %}

Basic steps

1. Install kubectl
2. Install the Operator

Install the latest release:

kubectl apply -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml

OR, install a specific version:

kubectl apply -f https://raw.githubusercontent.com/feast-dev/feast/refs/tags/<version>/infra/feast-operator/dist/install.yaml

3. Deploy a Feature Store

kubectl apply -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/config/samples/v1_featurestore.yaml

Verify the status:

$ kubectl get feast
NAME     STATUS   AGE
sample   Ready    2m21s

The above will install a simple FeatureStore CR like the following. By default, it will run the Online Store feature server:

apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: sample
spec:
  feastProject: my_project

More advanced FeatureStore CR examples can be found in the feast-operator samples directory.

If the operator was installed via OLM, upgrades are handled automatically. No manual steps are required — OLM recreates the operator Deployment during the upgrade process.

For most upgrades, re-running the install command is sufficient:

kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml

Version 0.61.0 updated the operator Deployment's spec.selector to include the app.kubernetes.io/name: feast-operator label, fixing a bug where the metrics service could accidentally target pods from other operators in shared namespaces.

Because Kubernetes treats spec.selector as an immutable field, upgrading directly from a pre-0.61.0 version with kubectl apply will fail with:

The Deployment "feast-operator-controller-manager" is invalid: spec.selector: Invalid value: ... field is immutable

To resolve this, delete the existing operator Deployment before applying the new manifest:

kubectl delete deployment feast-operator-controller-manager -n feast-operator-system --ignore-not-found=true
kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml

This is only required once. Existing FeatureStore CRs and their managed workloads (feature servers, registry, etc.) are not affected — the new operator pod will reconcile them automatically on startup. Future upgrades from 0.61.0 onward will not require this step.

{% hint style="success" %} Scaling & High Availability: The Feast Operator supports horizontal scaling via static replicas, HPA autoscaling, or external autoscalers like KEDA. Scaling requires DB-backed persistence for all enabled services.

When scaling is enabled, the operator auto-injects soft pod anti-affinity and zone topology spread constraints for resilience. You can also configure a PodDisruptionBudget to protect against voluntary disruptions.

See the Horizontal Scaling with the Feast Operator guide for configuration details, including HA options, or check the general recommendations on how to scale Feast. {% endhint %}

Sample scaling CRs are available at v1_featurestore_scaling_static.yaml and v1_featurestore_scaling_hpa.yaml.