# How to Deploy Feast on Kubernetes for Production: Helm Chart vs Operator Guide

> Deploy Feast on Kubernetes for production with a Helm chart for simple installs or the Feast Operator for native lifecycle management autoscaling and git sync.

- Repository: [Feast/feast](https://github.com/feast-dev/feast)
- Tags: how-to-guide
- Published: 2026-03-01

---

**Deploy Feast on Kubernetes for production using either the Feast Helm chart for simple declarative installs or the Feast Operator for Kubernetes-native lifecycle management including git sync and autoscaling.**

Feast (feast-dev/feast) is an open-source feature store that simplifies managing and serving machine learning features. When you deploy Feast on Kubernetes for production workloads, you can choose between two official methods: the **Feast Helm chart** for straightforward static deployments or the **Feast Operator** for dynamic, GitOps-driven management. Both approaches support the online feature server, materialization jobs as Kubernetes Jobs, and horizontal scaling.

## Prerequisites

Before you deploy Feast on Kubernetes, ensure you have the following tools installed:

- **kubectl** v1.11.3 or later
- **Helm** v3.x
- Access to a Kubernetes cluster (GKE, EKS, AKS, on-prem, or `kind`)

## Deploying with the Helm Chart

The Helm chart method provides a quick start for single-cluster deployments and is ideal when you need explicit control over each component.

### Add the Feast Helm Repository

Add the official Feast chart repository and update your local index:

```bash
helm repo add feast-charts https://feast-helm-charts.storage.googleapis.com
helm repo update

```

The repository URL is documented in [`infra/charts/feast/README.md`](https://github.com/feast-dev/feast/blob/main/infra/charts/feast/README.md) at lines 15-22.

### Configure Production Values

Create a [`values.yaml`](https://github.com/feast-dev/feast/blob/main/values.yaml) file to override defaults for production use. Store the registry in a durable object storage backend and configure resource limits:

```yaml
global:
  project: my_project
  registry:
    path: gs://my-bucket/registry.db
    cache_ttl_seconds: 60

feature-server:
  replicas: 3
  resources:
    limits:
      cpu: "2"
      memory: "4Gi"
    requests:
      cpu: "1"
      memory: "2Gi"
  redis:
    enabled: true
    usePassword: false

```

The default [`values.yaml`](https://github.com/feast-dev/feast/blob/main/values.yaml) structure is defined in [`infra/charts/feast/values.yaml`](https://github.com/feast-dev/feast/blob/main/infra/charts/feast/values.yaml), with documentation available in the chart README at lines 31-45.

### Install and Verify

Deploy Feast using your custom values:

```bash
helm install feast-release feast-charts/feast -f values.yaml

```

This command installs the root chart, which pulls in the Feature Server, Transformation Service, and optional Redis sub-charts as specified in [`infra/charts/feast/README.md`](https://github.com/feast-dev/feast/blob/main/infra/charts/feast/README.md) lines 9-13.

Verify the deployment:

```bash
kubectl get pods -l app.kubernetes.io/name=feature-server
kubectl get svc -l app.kubernetes.io/name=feature-server

```

Both Pods and Services should report `Ready` status.

### Production Considerations

For a production-grade Helm deployment, implement the following:

- **Persistence**: Store the registry in GCS, S3, or Azure Blob rather than local storage
- **TLS/Ingress**: Expose the feature server through a TLS-enabled Ingress controller (NGINX or Istio)
- **Monitoring**: Enable Prometheus scraping by setting `prometheus.io/scrape: "true"` annotations in your values
- **Autoscaling**: Replace static `replicas` with a Horizontal Pod Autoscaler (HPA) or KEDA `ScaledObject` as detailed in [`docs/how-to-guides/scaling-feast.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/scaling-feast.md) lines 122-130

## Deploying with the Feast Operator

The **Feast Operator** is the recommended production approach for teams requiring automated lifecycle management. It provides a `FeatureStore` Custom Resource Definition (CRD) that handles git-repo synchronization, rolling updates, and scaling policies.

### Install the Operator

Apply the latest stable Operator manifest using server-side apply:

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

```

Installation instructions are documented in [`infra/feast-operator/README.md`](https://github.com/feast-dev/feast/blob/main/infra/feast-operator/README.md) at lines 14-22.

### Create a FeatureStore Custom Resource

Define your production deployment in a YAML file. The following example configures a three-replica feature server with Redis and remote repository sync:

```yaml
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: prod
spec:
  feastProject: my_project
  featureServer:
    replicaCount: 3
    redis:
      enabled: true
  repo:
    git:
      url: https://github.com/your-org/feature-repo.git
      branch: main

```

The sample Custom Resource specification is documented in [`docs/how-to-guides/feast-on-kubernetes.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/feast-on-kubernetes.md) at lines 40-56 and available at [`infra/feast-operator/config/samples/v1_featurestore.yaml`](https://github.com/feast-dev/feast/blob/main/infra/feast-operator/config/samples/v1_featurestore.yaml).

### Apply and Verify

Deploy your FeatureStore resource:

```bash
kubectl apply -f featurestore.yaml

```

The Operator automatically creates the necessary Deployments, Services, ConfigMaps, and Jobs. Verify the status:

```bash
kubectl get feast
kubectl get pods -l app.kubernetes.io/name=feature-server

```

The `FeatureStore` resource should report `Ready` status within minutes, as shown in [`docs/how-to-guides/feast-on-kubernetes.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/feast-on-kubernetes.md) lines 46-52.

### Production Scaling and Security

The Operator supports multiple scaling strategies:

- **Static replicas**: Set `spec.featureServer.replicaCount` explicitly
- **HPA**: Create an HPA manifest targeting the `FeatureStore` sub-resource; the Operator respects external scaling controllers
- **KEDA**: Configure event-driven autoscaling using the patterns in [`docs/how-to-guides/scaling-feast.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/scaling-feast.md)

For authentication, enable **Kubernetes RBAC** or **OIDC** in your [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml) using the `KubernetesAuthConfig` model defined in [`sdk/python/feast/permissions/auth_model.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth_model.py) at lines 67-73. The Operator propagates these settings to feature server containers automatically.

## End-to-End CI/CD Deployment Script

Use the following script in your CI/CD pipeline to deploy a production-grade Feast instance on a fresh cluster:

```bash

# Install tooling

helm repo add feast-charts https://feast-helm-charts.storage.googleapis.com
helm repo update

# Install the Operator

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

# Deploy FeatureStore CR

cat <<EOF > featurestore.yaml
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: prod
spec:
  feastProject: my_project
  featureServer:
    replicaCount: 5
    redis:
      enabled: true
  repo:
    git:
      url: https://github.com/your-org/feature-repo.git
      branch: main
EOF
kubectl apply -f featurestore.yaml

# Verify deployment

kubectl wait --for=condition=Ready feast/prod --timeout=180s
kubectl get pods -l app.kubernetes.io/name=feature-server

```

Adjust `replicaCount` and registry storage paths to match your workload requirements.

## Key Source Files and Configuration Paths

Understanding these source files helps you customize your production deployment:

- **[`infra/charts/feast/README.md`](https://github.com/feast-dev/feast/blob/main/infra/charts/feast/README.md)** – Chart documentation, install commands, and configurable values reference
- **[`infra/charts/feast/values.yaml`](https://github.com/feast-dev/feast/blob/main/infra/charts/feast/values.yaml)** – Default Helm chart baseline for production overrides
- **[`infra/feast-operator/README.md`](https://github.com/feast-dev/feast/blob/main/infra/feast-operator/README.md)** – Operator lifecycle commands including install, upgrade, and uninstall procedures
- **[`infra/feast-operator/config/samples/v1_featurestore.yaml`](https://github.com/feast-dev/feast/blob/main/infra/feast-operator/config/samples/v1_featurestore.yaml)** – Sample `FeatureStore` CR manifest for production starting points
- **[`docs/how-to-guides/feast-on-kubernetes.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/feast-on-kubernetes.md)** – High-level deployment steps, verification commands, and troubleshooting
- **[`docs/how-to-guides/scaling-feast.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/scaling-feast.md)** – Detailed HPA and KEDA configuration for production autoscaling
- **[`sdk/python/feast/permissions/auth_model.py`](https://github.com/feast-dev/feast/blob/main/sdk/python/feast/permissions/auth_model.py)** – Authentication configuration models for Kubernetes RBAC and OIDC integration

## Production Checklist

Before serving production traffic, verify the following:

- **Cluster**: Kubernetes version 1.20+ with adequate node resources
- **Registry storage**: Durable bucket (GCS, S3, Azure) configured in `global.registry.path`
- **Scaling**: Static replicas, HPA, or KEDA configured based on traffic patterns
- **Security**: RBAC or OIDC enabled with least-privilege ServiceAccounts
- **Observability**: Prometheus scrape annotations applied; metrics endpoints accessible
- **Backup**: Registry backup procedures tested and scheduled
- **TLS**: Ingress controller serving HTTPS traffic to the feature server

## Summary

- **Choose the Helm chart** for single-cluster deployments requiring explicit manual control over YAML manifests and immediate customization
- **Choose the Feast Operator** for production environments requiring automated lifecycle management, git-repository synchronization, and native Kubernetes scaling policies
- **Store the registry** in cloud object storage (GCS, S3, or Azure Blob) rather than ephemeral local storage to prevent data loss
- **Enable autoscaling** using HPA or KEDA to handle variable request loads on the online feature server
- **Configure authentication** using the `KubernetesAuthConfig` model to secure your feature server endpoints

## Frequently Asked Questions

### What is the difference between the Helm chart and Feast Operator for production?

The **Helm chart** provides a static, template-based installation best for straightforward single-cluster setups where you manage updates manually. The **Feast Operator** provides a Kubernetes-native controller that manages the entire Feast lifecycle through Custom Resources, including automatic git-repository synchronization, rolling updates, and integration with HPA/KEDA for autoscaling, making it the recommended choice for complex production environments.

### How do I scale the Feast online feature server on Kubernetes?

You can scale the feature server three ways: set static `replicas` in your Helm [`values.yaml`](https://github.com/feast-dev/feast/blob/main/values.yaml) or `FeatureStore` CR, configure a Horizontal Pod Autoscaler (HPA) targeting the deployment, or implement KEDA for event-driven scaling. The Operator respects external HPA configurations on the `spec.replicas` field, while Helm deployments require you to manage the HPA manifest separately as documented in [`docs/how-to-guides/scaling-feast.md`](https://github.com/feast-dev/feast/blob/main/docs/how-to-guides/scaling-feast.md).

### Where should I store the Feast registry in production?

Store the registry in a durable remote backend such as **Google Cloud Storage (GCS)**, **Amazon S3**, or **Azure Blob Storage** using the `global.registry.path` configuration in Helm or the equivalent Operator setting. Avoid local filesystem storage for the registry in production, as pod restarts will result in registry data loss and feature consistency issues.

### How do I enable authentication for Feast on Kubernetes?

Enable authentication by configuring the `KubernetesAuthConfig` model in your [`feature_store.yaml`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml) to use either **Kubernetes RBAC** or **OIDC**. When using the Operator, these settings propagate automatically to the feature server containers. For Helm deployments, mount the authentication configuration as a ConfigMap or secret and reference it in your [`values.yaml`](https://github.com/feast-dev/feast/blob/main/values.yaml) environment variables.