This page covers deployment strategies and patterns for running Feast in production environments. It provides an overview of the deployment architecture, available deployment mechanisms, and key considerations for productionizing Feast components.
For detailed information on:
For development and testing workflows, see Getting Started and CLI. For feature server implementation details, see Feature Serving.
Feast deployments consist of several core components that can be deployed independently based on your use case. The architecture separates the control plane (feature definitions and metadata) from the data plane (feature storage and serving).
Deployment Architecture with Code Entities
Sources: sdk/python/feast/feature_store.py300-500 sdk/python/feast/infra/registry/base_registry.py50-100 sdk/python/feast/infra/online_stores/online_store.py40-80 sdk/python/feast/infra/offline_stores/offline_store.py50-100
The core interfaces that define the deployment architecture are:
OfflineStore - Historical feature retrieval interface at sdk/python/feast/infra/offline_stores/offline_store.pyOnlineStore - Low-latency serving interface at sdk/python/feast/infra/online_stores/online_store.pyBaseRegistry - Metadata storage interface at sdk/python/feast/infra/registry/base_registry.pyFeatureStore - Main SDK entrypoint at sdk/python/feast/feature_store.pySources: docs/how-to-guides/running-feast-in-production.md1-9 README.md40-43 sdk/python/feast/feature_store.py1-100
The table below summarizes the key components and their deployment requirements:
| Component | Required | Deployment Options | Purpose |
|---|---|---|---|
| Registry | Yes | File/SQL/Remote Server | Stores feature definitions and metadata |
| Offline Store | For training | Cloud DWH or local files | Historical feature retrieval |
| Online Store | For serving | Redis/DynamoDB/SQLite/etc | Low-latency feature serving |
| Feature Server | For serving | Docker/K8s Pod | HTTP/gRPC API for online features |
| Materialization | For batch loading | CronJob/Airflow/Lambda | Sync offline→online data |
| Web UI | Optional | Docker/K8s Pod | Feature discovery interface |
Sources: docs/how-to-guides/running-feast-in-production.md21-26
For local development and testing, Feast can run without external infrastructure dependencies:
This configuration uses:
data/registry.dbdata/online_store.dbThe feast apply and feast materialize commands run in-process without additional services.
Sources: docs/getting-started/quickstart.md106-117 examples/quickstart/quickstart.ipynb189-216
Feast provides pre-built Docker images for feature servers and related services. Images are published to quay.io/feastdev:
| Image | Purpose | Build Context | Default Port |
|---|---|---|---|
feature-server | Python feature server | infra/docker/feature-server/ | 6566 |
feature-transformation-server | Java transformation service | java/infra/docker/feature-transformation-server/ | 6566 |
feast-operator | Kubernetes operator | infra/feast-operator/Dockerfile | - |
Example Docker run command for the Python feature server:
The container runs the feast CLI command defined in sdk/python/feast/cli.py with the serve subcommand that starts a FastAPI server in sdk/python/feast/ui/service.py
The build process uses multi-architecture builds supporting linux/amd64 and linux/arm64. Build workflows are defined in:
The image tags follow semantic versioning and are automatically published on releases.
Sources: .github/workflows/build_wheels.yml69-108 .github/workflows/master_only.yml87-130 infra/feast-operator/Makefile55-56
Kubernetes is the recommended production deployment environment. Feast provides two mechanisms for Kubernetes deployment:
Kubernetes Deployment Options with Code Structure
Helm Charts provide traditional infrastructure-as-code deployment:
Kubernetes Operator provides declarative, GitOps-friendly deployment:
FeatureStore Custom Resource Definition (CRD) defined at infra/feast-operator/config/crd/bases/feast.dev_featurestores.yamlFeatureStoreReconciler at infra/feast-operator/internal/controller/featurestore_controller.goFeastServices at infra/feast-operator/internal/controller/services/services.goInstallation via kubectl:
The --server-side flag is required because the CRD includes multiple API versions that exceed annotation size limits.
The operator image is published as quay.io/feastdev/feast-operator:{VERSION} and feature server as quay.io/feastdev/feature-server:{VERSION} where VERSION is defined in infra/feast-operator/api/feastversion/version.go16
Sources: infra/feast-operator/README.md14-28 docs/how-to-guides/feast-on-kubernetes.md20-45 infra/feast-operator/api/v1alpha1/featurestore_types.go1-100 infra/feast-operator/internal/controller/featurestore_controller.go1-100
The registry is the single source of truth for feature definitions. In production, use a scalable registry backend:
Registry Backend Comparison
Default option, stores protobuf in a file (local, S3, GCS):
Limitations: Not safe for concurrent writers. Each write rewrites the entire file.
Sources: docs/how-to-guides/running-feast-in-production.md32-37
Recommended for production with concurrent operations:
Supports transactional updates to individual registry objects. Registry implementation at sdk/python/feast/infra/registry/sql.py
Note: The Java feature server does not support SQL registry yet.
Sources: docs/how-to-guides/running-feast-in-production.md32-37 sdk/python/tests/unit/infra/registry/test_sql_registry.py23-59
For Snowflake-centric deployments:
Sources: docs/reference/registries/metadata.md16-23
Optional abstraction layer that serves the registry via gRPC:
Allows centralized registry access without direct database connections. Not widely used in practice.
Sources: README.md232
Feature servers expose the get_online_features API for real-time inference. Feast provides three implementations:
Feature Server Selection Guide
Command to start: feast serve or feast serve_transformations
Default port: 6566
Supports:
Dockerfile at infra/docker/feature-server/Dockerfile
Sources: docs/roadmap.md62 README.md227
Higher performance alternative written in Go. Does not support all Python SDK features.
Default port: 6566
Requires transformation service for on-demand features:
Sources: docs/reference/registries/metadata.md27-29 README.md230
For JVM-based deployment environments. Packaged via Helm chart.
Sources: README.md229
The FeatureStore custom resource (defined in FeatureStoreSpec at infra/feast-operator/api/v1alpha1/featurestore_types.go69-78) declares the desired state:
The FeatureStoreReconciler at infra/feast-operator/internal/controller/featurestore_controller.go60-130 processes this CR and calls FeastServices.Deploy() at infra/feast-operator/internal/controller/services/services.go52-152 which creates:
Deployment with containers for each service (registry, online, offline, UI) via setDeployment() at infra/feast-operator/internal/controller/services/services.go382-405Service resources for network routing via createService() at infra/feast-operator/internal/controller/services/services.go304-315ConfigMap containing base64-encoded feature_store.yaml generated by GetServiceFeatureStoreYamlBase64() at infra/feast-operator/internal/controller/services/repo_config.go29-36PersistentVolumeClaim for registry storage via createPVC() at infra/feast-operator/internal/controller/services/services.go362-380ServiceAccount for pod identity via createServiceAccount() at infra/feast-operator/internal/controller/services/services.go317-328The operator continuously reconciles the actual state with the desired state defined in the CR.
Sources: docs/reference/feature-servers/offline-feature-server.md18-30 docs/how-to-guides/feast-on-kubernetes.md54-66 infra/feast-operator/api/v1alpha1/featurestore_types.go69-78 infra/feast-operator/internal/controller/services/services.go52-152
The offline feature server exposes offline store operations via Apache Arrow Flight (gRPC):
Default port: 8815
Use cases:
Sources: docs/reference/feature-servers/offline-feature-server.md1-31
Materialization moves data from offline stores to online stores using the FeatureStore.materialize() or FeatureStore.materialize_incremental() methods defined at sdk/python/feast/feature_store.py800-900 In production, this requires orchestration:
Materialization Orchestration Patterns with Code Paths
The materialization process:
OfflineStore.get_historical_features() at sdk/python/feast/infra/offline_stores/offline_store.py100-200OnlineStore.online_write_batch() at sdk/python/feast/infra/online_stores/online_store.py80-120Registry.apply_materialization() at sdk/python/feast/infra/registry/base_registry.py200-250Example Airflow task using PythonOperator:
The Airflow worker needs read/write access to the registry.
Sources: docs/how-to-guides/running-feast-in-production.md64-101
The operator can deploy CronJobs that execute feast materialize-incremental via the FeastCronJob configuration at infra/feast-operator/api/v1alpha1/featurestore_types.go112-156:
The operator's deployCronJob() method at infra/feast-operator/internal/controller/services/cronjob.go creates a Kubernetes CronJob resource that executes commands in the feature store deployment pod using kubectl exec. This ensures the CronJob runs with the same environment, configuration, and credentials as the main deployment.
Default commands if not specified are:
feast apply - Synchronize feature definitionsfeast materialize-incremental $(date -u +'%Y-%m-%dT%H:%M:%S') - Materialize features up to current timeSources: infra/feast-operator/api/v1alpha1/featurestore_types.go112-156 infra/feast-operator/internal/controller/services/services.go147-149
For serverless materialization on AWS:
Sources: docs/roadmap.md58 README.md223
Production deployments typically require environment-specific configuration. Feast supports environment variable substitution in feature_store.yaml:
This enables a single feature_store.yaml template across environments (dev, staging, production) with environment-specific secrets.
Sources: docs/how-to-guides/running-feast-in-production.md209-221
CI/CD Workflow for Feature Definitions
Recommended workflow:
feast plan to show changesfeast apply to update registryThe CI/CD system requires write access to the registry and Kubernetes cluster.
Sources: docs/how-to-guides/running-feast-in-production.md27-49
Production deployments typically involve multiple environments (staging, production). Three common approaches:
| Approach | Structure | Tradeoffs |
|---|---|---|
| Separate branches | staging and production branches | Clear separation, manual promotion |
| Separate repos | staging/ and production/ directories | Duplication, copy-paste required |
| Shared definitions | Shared Python files, separate configs | DRY principle, requires careful testing |
Example structure for separate repos:
├── staging/
│ ├── driver_repo.py
│ └── feature_store.yaml
├── production/
│ ├── driver_repo.py
│ └── feature_store.yaml
└── .github/workflows/
├── staging.yml
└── production.yml
Sources: docs/how-to-guides/structuring-repos.md14-103
Feast deployment involves:
feast apply and infrastructure updatesThe Kubernetes Operator provides the most streamlined deployment experience for cloud-native environments, while Helm charts offer flexibility for custom configurations.
For implementation details on each deployment mechanism, see the child pages:
Sources: docs/how-to-guides/running-feast-in-production.md224-239 docs/how-to-guides/feast-on-kubernetes.md1-72
Refresh this wiki
This wiki was recently refreshed. Please wait 4 days to refresh again.