Docker Images

Relevant source files

• .github/fork_workflows/fork_pr_integration_tests_aws.yml
• .github/fork_workflows/fork_pr_integration_tests_gcp.yml
• .github/fork_workflows/fork_pr_integration_tests_snowflake.yml
• .github/workflows/build_wheels.yml
• .github/workflows/linter.yml
• .github/workflows/master_only.yml
• .github/workflows/nightly-ci.yml
• .github/workflows/pr_integration_tests.yml
• .github/workflows/pr_local_integration_tests.yml
• .github/workflows/publish.yml
• .github/workflows/release.yml
• .github/workflows/unit_tests.yml
• .releaserc.js
• Makefile
• infra/scripts/install-helm.sh
• pyproject.toml
• sdk/python/requirements/py3.10-ci-requirements.txt
• sdk/python/requirements/py3.10-minimal-requirements.txt
• sdk/python/requirements/py3.10-minimal-sdist-requirements.txt
• sdk/python/requirements/py3.10-requirements.txt
• sdk/python/requirements/py3.11-ci-requirements.txt
• sdk/python/requirements/py3.11-minimal-requirements.txt
• sdk/python/requirements/py3.11-minimal-sdist-requirements.txt
• sdk/python/requirements/py3.11-requirements.txt
• sdk/python/requirements/py3.12-ci-requirements.txt
• sdk/python/requirements/py3.12-minimal-requirements.txt
• sdk/python/requirements/py3.12-minimal-sdist-requirements.txt
• setup.py

This document describes the Docker images built and published by the Feast project. It covers the different image types, their build process, publishing workflows, and how they are used in production deployments. For information about deploying these images using Helm charts, see Helm Charts. For Kubernetes Operator deployment patterns, see Kubernetes Operator.

Overview

Feast builds and publishes multiple Docker images to support different deployment scenarios and language runtimes. All production images are published to the quay.io/feastdev registry, while CI builds are published to quay.io/feastdev-ci. The images support multi-architecture builds (linux/amd64 and linux/arm64) and are built using Docker BuildKit.

Image Types

Feast maintains five primary Docker images, each serving a specific purpose in the architecture:

Image Name	Purpose	Base Language	Dockerfile Location
feature-server	Python-based HTTP/gRPC feature serving	Python	sdk/python/feast/infra/feature_servers/multicloud/Dockerfile
feature-transformation-server	Java-based transformation service	Java	sdk/python/feast/infra/transformation_servers/Dockerfile
feature-server-java	Java-based feature server (legacy)	Java	java/infra/docker/feature-server/Dockerfile
feast-operator	Kubernetes operator for GitOps deployments	Go	infra/feast-operator/Dockerfile
go-feature-server	High-performance Go feature server	Go	go/infra/docker/feature-server/Dockerfile

Sources: Makefile600-646

Feature Server (Python)

The primary feature server implementation built on FastAPI and uvicorn. It provides HTTP and gRPC endpoints for online feature retrieval and supports all Feast online stores.

Build Target: build-feature-server-docker

Key Characteristics:

• Includes the full Feast Python SDK with all dependencies
• Supports online feature serving via /get-online-features endpoint
• Can be deployed standalone or via Helm charts
• Base image uses Python 3.10+

Sources: Makefile608-612

Feature Transformation Server

A Java-based service that handles on-demand feature transformations using the Java transformation engine. This server is deployed alongside the Python feature server when Java-based transformations are required.

Build Target: build-feature-transformation-server-docker

Build Process:

1. Maven build creates Java artifacts
2. Docker build copies artifacts and sets up JVM environment
3. Image tagged with VERSION argument

Sources: Makefile617-620

Feast Operator

A Kubernetes operator that manages Feast deployments declaratively using Custom Resource Definitions (CRDs). It watches FeatureStore CRD resources and reconciles desired state.

Build Target: build-feast-operator-docker

Build Process: The operator build delegates to the operator's own Makefile:

cd infra/feast-operator && \
IMAGE_TAG_BASE=$(REGISTRY)/feast-operator \
VERSION=$(VERSION) \
$(MAKE) docker-build

Sources: Makefile636-640

Go Feature Server

A high-performance alternative to the Python feature server, optimized for low-latency serving. Supports a subset of online stores with native Go implementations.

Build Target: build-go-feature-server-docker

Requirements:

• Requires Protocol Buffer compilation: make compile-protos-go
• Uses Go 1.22.9+ (as of this writing)

Sources: Makefile642-646

Build System Architecture

Sources: Makefile600-646

Build Workflow

The Docker images are built using docker buildx with multi-architecture support. All builds use the --load flag for local development or omit it for CI/CD pipelines that push directly to registries.

Common Build Parameters

All image builds accept the following parameters:

Parameter	Description	Default	Example
REGISTRY	Docker registry prefix	N/A	quay.io/feastdev
VERSION	Image version tag	N/A	v0.38.0 or ${GITHUB_SHA}

Build Commands

Feature Server:

Feature Transformation Server:

Java Feature Server:

Sources: Makefile608-628

CI/CD Build Pipeline

Sources: .github/workflows/master_only.yml87-131 .github/workflows/build_wheels.yml69-108

Master Branch Builds

On every push to the master branch, all Docker images are built and published to the CI registry:

1. Trigger: Push to master branch
2. Registry: quay.io/feastdev-ci
3. Tags:
   • ${GITHUB_SHA} - Unique commit hash
   • develop - Latest development build
4. Matrix Strategy: Builds all components in parallel

Sources: .github/workflows/master_only.yml87-131

Release Builds

On tagged releases (matching v*.*.*), images are built and published to the production registry:

1. Trigger: Push tag matching v*.*.* or manual workflow dispatch
2. Registry: quay.io/feastdev
3. Build Process:
   • Python wheels are built first
   • Docker images are built with the release version
   • Images are verified before publishing
4. Tags:
   • VERSION_WITHOUT_PREFIX (e.g., 0.38.0)
   • latest (for stable releases)

Sources: .github/workflows/build_wheels.yml69-108 .github/workflows/publish.yml48-54

Build Verification

The verify-python-wheels job validates Docker images before publishing:

Verification Steps:

1. Download Python wheel artifact
2. Build Docker image with wheel
3. Verify feast version output matches expected version
4. Smoke tests (currently disabled)

Sources: .github/workflows/build_wheels.yml109-196

Development Images

Feast provides specialized development images for local testing and iteration:

Target	Image Tag	Purpose
build-feature-server-dev	feastdev/feature-server:dev	Local Python server development
build-feature-server-dev-docker	$(REGISTRY)/feature-server:$(VERSION)	CI-built dev server
build-java-docker-dev	feastdev/feature-transformation-server:dev	Local Java transformation service
build-go-docker-dev	feastdev/feature-server-go:dev	Local Go server development

Development Dockerfiles

Development images use alternative Dockerfiles optimized for faster iteration:

• Python Feature Server: sdk/python/feast/infra/feature_servers/multicloud/Dockerfile.dev
• Java Services: java/infra/docker/feature-server/Dockerfile.dev

These dev Dockerfiles typically:

• Skip production optimizations
• Include development tools
• Mount source code as volumes
• Use hot-reloading where applicable

Sources: Makefile651-678

Building Dev Images Locally

Sources: Makefile653-678

Multi-Architecture Support

All production Docker images support multiple architectures using Docker BuildKit and QEMU:

Supported Architectures:

• linux/amd64 - Standard x86_64 architecture
• linux/arm64 - ARM64/aarch64 architecture (Apple Silicon, ARM servers)

Setup in CI

Platform-Specific Considerations:

For macOS (especially Apple Silicon), some builds require explicit platform specification:

Sources: .github/workflows/master_only.yml107-111 Makefile663-666

Image Registry Configuration

CI Registry (Development)

• URL: quay.io/feastdev-ci
• Credentials: QUAYIO_CI_USERNAME and QUAYIO_CI_TOKEN secrets
• Purpose: Continuous testing and development
• Retention: Images tagged with commit SHAs and develop

Production Registry

• URL: quay.io/feastdev
• Credentials: QUAYIO_USERNAME and QUAYIO_PASSWORD secrets
• Purpose: Stable releases for production use
• Retention: Versioned releases and latest tag

Sources: .github/workflows/master_only.yml94-118

Version Management

Docker image versions are synchronized with the Feast release version:

Version Extraction Process:

1. Git tag or custom version input provides base version
2. .github/actions/get-semantic-release-version action extracts version
3. Outputs two formats:
   • release_version: Full version with prefix (e.g., v0.38.0)
   • version_without_prefix: Numeric version (e.g., 0.38.0)
4. Docker images are tagged with version_without_prefix

Sources: .github/workflows/build_wheels.yml48-105 .releaserc.js1-150

Build Dependencies

Python Feature Server Dependencies

The Python feature server image includes dependencies from:

• Base requirements: setup.py32-63
• Optional extras configured via pip install feast[extra]
• Full CI dependencies: sdk/python/requirements/py3.11-ci-requirements.txt1-10000

Minimal vs Full Images

While Feast currently publishes full-featured images, the dependency system supports minimal builds:

Dependency Set	File	Purpose
Base	py3.11-requirements.txt	Core Feast functionality
Minimal	py3.11-minimal-requirements.txt	Minimal production deployment
Minimal (sdist)	py3.11-minimal-sdist-requirements.txt	Source distribution builds
CI	py3.11-ci-requirements.txt	Testing and development

Sources: sdk/python/requirements/py3.11-requirements.txt1-100 sdk/python/requirements/py3.11-minimal-requirements.txt1-100 setup.py279-292

Build Optimization

Disk Space Management

CI builds use the jlumbroso/free-disk-space action to free up space on GitHub runners before building large images:

This removes unnecessary build tools and packages, freeing ~14GB of space.

Sources: .github/workflows/master_only.yml97-106

Caching Strategy

Docker BuildKit automatically caches layers, but the build process also:

• Reuses Python wheels built in previous steps
• Caches Maven dependencies for Java builds
• Uses multi-stage builds to minimize final image size

Sources: .github/workflows/build_wheels.yml31-66

Usage in Deployment

The built Docker images are consumed by:

1. Helm Charts: Feature server and transformation server charts reference these images (see Helm Charts)
2. Kubernetes Operator: Deploys and manages these images declaratively (see Kubernetes Operator)
3. Direct Deployment: Can be run standalone with docker run or in container orchestration platforms

Example Docker run command:

Sources: Makefile608-612