how-to-guide

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

March 1, 2026 feast-dev/feast ↗

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:

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 at lines 15-22.

Configure Production Values

Create a values.yaml file to override defaults for production use. Store the registry in a durable object storage backend and configure resource limits:

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 structure is defined in 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:

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 lines 9-13.

Verify the deployment:

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 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:

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 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:

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 at lines 40-56 and available at infra/feast-operator/config/samples/v1_featurestore.yaml.

Apply and Verify

Deploy your FeatureStore resource:

kubectl apply -f featurestore.yaml

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

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 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

For authentication, enable Kubernetes RBAC or OIDC in your feature_store.yaml using the KubernetesAuthConfig model defined in 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:


# 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 – Chart documentation, install commands, and configurable values reference
infra/charts/feast/values.yaml – Default Helm chart baseline for production overrides
infra/feast-operator/README.md – Operator lifecycle commands including install, upgrade, and uninstall procedures
infra/feast-operator/config/samples/v1_featurestore.yaml – Sample FeatureStore CR manifest for production starting points
docs/how-to-guides/feast-on-kubernetes.md – High-level deployment steps, verification commands, and troubleshooting
docs/how-to-guides/scaling-feast.md – Detailed HPA and KEDA configuration for production autoscaling
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 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.

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 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 environment variables.

Have a question about this repo?

These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:

Share the following with your agent to get started:

curl -s "https://instagit.com/install.md"

Add to your MCP client configuration:

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}

Ask your agent:

"Use Instagit MCP to understand how feast-dev/feast works."

Works with

Claude Codex Cursor VS Code OpenClaw Any MCP Client

Maintain an open-source project? Get it listed too →