Skip to main content
Flyte can be deployed in several configurations, ranging from a single Docker container on your laptop to a multi-cluster production system. This guide helps platform engineers and DevOps teams understand the available deployment paths and choose the right one.

Architecture

A Flyte cluster is composed of the following core services:
ComponentRole
FlyteAdminAPI server that accepts workflow registrations and execution requests over HTTP and gRPC
FlytePropellerKubernetes controller that drives workflow execution by reconciling FlyteWorkflow CRDs
FlyteConsoleReact-based web UI for browsing workflows, executions, and artifacts
DataCatalogCaching service that stores and retrieves task output metadata for memoization
FlyteSchedulerNative cron-style scheduler that triggers time-based workflow launches
All persistent state lives in two external dependencies: a PostgreSQL database (used by FlyteAdmin and DataCatalog) and an object store (S3, GCS, or Azure Blob, used for task inputs, outputs, and workflow metadata).

Deployment models

Local sandbox

Single Docker container running k3s, MinIO, and PostgreSQL. Ideal for development and testing. Start in one command with flytectl demo start.

Single binary

All Flyte services compiled into a single Go binary, deployed on Kubernetes using the flyte-binary Helm chart. Best for teams that want a production-capable cluster without multi-service complexity.

Full (flyte-core)

Each Flyte component runs as an independent Kubernetes Deployment. Use the flyte-core Helm chart when you need fine-grained scaling, multi-cluster execution, or custom per-component configuration.

Choosing a deployment model

Use the local sandbox. Run flytectl demo start and you have a fully functional Flyte cluster in under two minutes. No Kubernetes knowledge required.
Use the single binary (flyte-binary Helm chart) deployed on EKS or GKE. It supports all plugins, authentication, and blob storage backends. It is simpler to operate than the full chart because all components share one pod.
Use the flyte-core Helm chart. This deploys FlyteAdmin, FlytePropeller, DataCatalog, and FlyteConsole as separate Deployments, each with independent resource limits and replica counts. It is required for the multi-cluster execution model.
Use the single binary or flyte-core chart with MinIO as the object store. See the on-premises guide.

Platform guides

AWS (EKS)

Deploy on Amazon EKS with S3, RDS PostgreSQL, and IAM Roles for Service Accounts (IRSA).

GCP (GKE)

Deploy on Google Kubernetes Engine with GCS, Cloud SQL, and Workload Identity.

On-premises

Deploy on self-hosted Kubernetes with MinIO and a local PostgreSQL instance.

Single binary

Bootstrap Flyte on a single Kubernetes node using the flyte-binary Helm chart.

Configuration & security

Configuration overview

How config files, Helm values, and environment variables interact.

Authentication

OIDC/OAuth2 setup with Okta, Google, Azure AD, and Keycloak.

Storage

Configure S3, GCS, Azure Blob, and MinIO backends.

Secrets

Inject secrets into task pods from Kubernetes Secrets, AWS Secrets Manager, or Vault.

RBAC

Map OIDC claims to Flyte project and domain permissions.

Security overview

Non-root containers, network policies, TLS, and audit logging.

Plugin guides

Plugins overview

Enable backend plugins that extend Flyte’s task execution capabilities.

Spark

Run Apache Spark jobs on Kubernetes using spark-on-k8s-operator.

Ray

Run distributed Ray jobs using the KubeRay operator.

KFPyTorch

Run distributed PyTorch training with the Kubeflow training-operator.

Build docs developers (and LLMs) love