4 — Registry Topology

The Feast registry stores metadata about feature views, entities, and feature services. The operator supports three topology options:

Topology

Use case

Local (file or DB)

Self-contained deployment; registry runs alongside other services

Local + server

Local registry exposed as a gRPC / REST server for remote clients

Remote

Multiple FeatureStore CRs share a single registry managed by another CR

Local registry

File-backed (default)

services:
  registry:
    local:
      persistence:
        file:
          path: registry.db
          pvc:
            create: {}
            mountPath: /data/registry

DB-backed (SQL / Snowflake)

apiVersion: v1
kind: Secret
metadata:
  name: feast-data-stores
stringData:
  sql: |
    path: postgresql+psycopg://feast:feast@postgres:5432/feast  #pragma: allowlist secret
    cache_ttl_seconds: 60
---
services:
  registry:
    local:
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores   # reads key "sql"

Exposing the registry as a server

Add server: {} under registry.local to expose it on port 6570:

services:
  registry:
    local:
      server: {}                       # exposes gRPC on 6570
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores

The registry server also supports REST and gRPC independently:

registry:
  local:
    server:
      restAPI: true    # enable REST API (default: true when server is set)
      grpc: true       # enable gRPC (default: true when server is set)

MCP on the registry server

When the REST API is enabled, you can additionally expose registry metadata as MCP (Model Context Protocol) tool endpoints for LLM agents:

services:
  registry:
    local:
      server:
        restAPI: true
        mcp:
          enabled: true
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores

The operator writes registry.mcp.enabled: true into feature_store.yaml. A validation rule enforces that restAPI must be true when mcp.enabled is true.

See Guide 3 — Serving & Observability for more details and the full MCP configuration reference.

Remote registry

A remote registry lets multiple FeatureStore CRs (e.g. in different namespaces or teams) share a single registry. One CR owns the registry; the others point at it.

Using a hostname

Point at any existing Feast registry server endpoint:

services:
  registry:
    remote:
      hostname: feast-registry.feast-system.svc.cluster.local:6570

Using `feastRef` (recommended for operator-managed registries)

feastRef lets one FeatureStore CR reference another CR's registry without hard-coding hostnames. The operator resolves the Service name automatically:

# CR that owns the registry (in namespace "feast-system")
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: registry-owner
  namespace: feast-system
spec:
  feastProject: shared_project
  services:
    registry:
      local:
        server: {}
        persistence:
          store:
            type: sql
            secretRef:
              name: feast-data-stores

# CR that consumes the shared registry (in namespace "team-a")
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: team-a-store
  namespace: team-a
spec:
  feastProject: shared_project
  services:
    registry:
      remote:
        feastRef:
          name: registry-owner
          namespace: feast-system      # omit if same namespace

Remote registry with TLS

If the remote registry server uses TLS, provide the CA certificate so clients can verify it:

services:
  registry:
    remote:
      feastRef:
        name: registry-owner
        namespace: feast-system
      tls:
        configMapRef:
          name: registry-ca-cert       # ConfigMap containing the CA cert
        certKeyName: ca.crt            # key inside the ConfigMap (default: ca.crt)

All-remote topology

For teams that deploy services independently, all services can use remote endpoints:

apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: client-store
spec:
  feastProject: my_project
  services:
    offlineStore:
      remote:
        hostname: feast-offline.feast-system.svc.cluster.local:8815
    onlineStore:
      remote:
        hostname: feast-online.feast-system.svc.cluster.local:6566
    registry:
      remote:
        feastRef:
          name: central-registry
          namespace: feast-system

Client-side configuration (auto-generated ConfigMap)

When the operator deploys a FeatureStore CR, it automatically creates a ConfigMap named feast-<name>-client in the same namespace. This ConfigMap contains a ready-to-use feature_store.yaml that points at the deployed remote services (online store, offline store, and registry).

For example, a CR named testing produces a ConfigMap feast-testing-client:

# ConfigMap: feast-testing-client (auto-generated by the operator)
apiVersion: v1
kind: ConfigMap
metadata:
  name: feast-testing-client
data:
  feature_store.yaml: |
    project: testing
    provider: local
    online_store:
        path: https://feast-testing-online.feast.svc.cluster.local:443
        type: remote
        cert: /etc/pki/tls/custom-certs/ca-bundle.crt
    registry:
        path: feast-testing-registry.feast.svc.cluster.local:443
        registry_type: remote
        cert: /etc/pki/tls/custom-certs/ca-bundle.crt
    auth:
        type: no_auth
    entity_key_serialization_version: 3

Using the client ConfigMap in-cluster

Mount the ConfigMap into your application pod so the Feast SDK discovers the configuration automatically:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-serving-app
spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: feast-client-config
              mountPath: /opt/feast
              readOnly: true
      volumes:
        - name: feast-client-config
          configMap:
            name: feast-testing-client

Then initialize the Feast store from the mounted path:

from feast import FeatureStore

store = FeatureStore(repo_path="/opt/feast")

Using the client ConfigMap outside the cluster

Copy the ConfigMap content to your local feature_store.yaml for development or testing outside the cluster. Adjust hostnames and TLS paths as needed (e.g. use kubectl port-forward or an Ingress endpoint):

kubectl get configmap feast-testing-client -o jsonpath='{.data.feature_store\.yaml}' > feature_store.yaml