Deployment Paths#

The articles in this section will guide a new Flyte administrator through deploying Flyte.

The most complex parts of a Flyte deployment are authentication, ingress, DNS, and SSL support. Due to the complexity introduced by these components, we recommend deploying Flyte without these at first and relying on K8s port forwarding to test your Flyte cluster. After the base deployment is tested, these additional features can be turned on more seamlessly.

Components of a Flyte Deployment#


We recommend working with your infrastructure team to set up the cloud service requirements below.

Relational Database#

Two of Flyte’s components, FlyteAdmin and DataCatalog, rely on PostgreSQL to store persistent records. In the sandbox deployment, a containerized version of Postgres is included but for a proper Flyte installation, we recommend one of the cloud provided databases.


We recommend the following services, depending on your cloud platform of choice:

Production Grade Object Store#

Core Flyte components such as FlyteAdmin, FlytePropeller, DataCatalog, and user runtime containers rely on an object store to hold files. The sandbox deployment comes with a containerized Minio, which offers AWS S3 compatibility.


We recommend swapping this out for a production-grade object store, depending on your cloud platform of choice:

Cluster Configuration#

Flyte configures K8s clusters to work with it. For example, as your Flyte userbase evolves, adding new projects is as simple as registering them through the command line:

flytectl create project \
    --id my-flyte-project \
    --name "My Flyte Project" \
    --description "My first project onboarding onto Flyte"

Once you invoke this command, this project should immediately show up in the Flyte console after refreshing.

Flyte runs at a configurable cadence that ensures that all Kubernetes resources necessary for the new project are created and new workflows can successfully be registered and executed within it.


For more information, see flytectl.

Flyte Deployment Paths#

There are three different paths for deploying a Flyte cluster:

Deployment Path




This uses portable replacements for the relational database and blob store. It’s good for testing out and experimenting with Flyte.

Single Cluster

This bundles Flyte as one executable. It runs on a single K8s cluster and supports all of Flyte’s extensions and plugins. Once the simple deployment is established, you can follow steps to productionize it.

Multiple Clusters

For large-scale deployments that require multiple K8s clusters. Flyte’s control plane (FlyteAdmin, FlyteConsole, and DataCatalog) is separated from Flyte’s execution engine, FlytePropeller, which runs typically once per compute cluster.


We recommend the Single Cluster option for a capable though not massively scalable cluster.

This option is appropriate if all your compute can fit on one EKS cluster . As of this writing, a single Flyte cluster can handle more than 13,000 nodes.

Whatever path you choose, note that FlytePropeller itself can be sharded as well, though typically it’s not required.


Flyte uses Helm as the K8s release packaging solution, though you may still see some old Kustomize artifacts in the flyte repo. The core Flyte team maintains Helm charts that correspond with the latter two deployment paths.


Technically there is a Helm chart for the sandbox environment as well, but it’s been tested only with the Dockerized K3s bundled container.

Deployment Tips and Tricks#

Due to the many choices and constraints that you may face in your organization, the specific steps for deploying Flyte can vary significantly. For example, which cloud platform to use is typically a big fork in the road for many, and there are many choices to make in terms of ingresses, auth providers, and versions of different dependent libraries that may interact with other parts of your stack.

In addition to searching and posting on the Flyte Slack community, we have a Github Discussion section dedicated to deploying Flyte. Feel free to submit any hints you’ve found helpful as a discussion, ask questions, or simply document what worked or what didn’t work for you.