Deployment overview

Before you install Flyte, it helps to understand what the deployment is made of and which external dependencies you need to provide yourself.

Architecture

Flyte runs as a single unified binary. One container image bundles all of the backend components into one process:

At a high level, clients reach Flyte through a single HTTP ingress that fronts the console and the Flyte binary. The binary bundles the backend services into one process, reconciles task pods onto Kubernetes, and depends on an external database and object store:

            flowchart TB
    client["SDK & CLI"]

    subgraph cluster["Kubernetes cluster"]
        ingress["HTTP ingress"]
        console["Console<br/>(static SPA)"]

        subgraph binary["Flyte binary (unified)"]
            runs["Runs service"]
            controller["Actions / task controller"]
            dataproxy["Data proxy"]
            apps["App service"]
        end

        pods["Task pods & app deployments"]
    end

    db[("PostgreSQL")]
    store[("Object store<br/>S3 / GCS / Azure")]

    client -->|Connect over HTTP| ingress
    ingress -->|/v2| console
    ingress -->|flyteidl2.* + auth| binary
    console -.->|API on same origin| ingress

    runs --> db
    controller --> pods
    apps --> pods
    dataproxy -->|signed URLs| store
    client -.->|upload / download| store
    pods --> store
        

A second image serves the web console as a static single-page application. It is deployed as its own Deployment and Service but has no backend configuration of its own — it talks to the Flyte API on the same origin (same ingress host) and is served under a base path (default /v2, configurable via console.basePath).

Networking

Flyte clients (the SDK and CLI) speak buf Connect over HTTP, so a single HTTP ingress serves the console, the API, and the auth-discovery endpoints — there is no separate gRPC port to expose. The single ingress routes, by path, to two backends:

• Console Service: console.basePath (default /v2, and /v2/*)
• Flyte HTTP Service: this service consists of:
  • The flyteidl2.* Connect service paths, for example: /flyteidl2.project.ProjectService, /flyteidl2.workflow.RunService, /flyteidl2.task.TaskService, /flyteidl2.dataproxy.DataProxyService
  • The auth-discovery paths, for example: /.well-known/oauth-authorization-server, /flyteidl2.auth.*

External dependencies

The chart deploys the Flyte binary and console, but it does not provision the infrastructure they depend on. Provision these before installing, regardless of cloud:

Kubernetes cluster

Use a supported Kubernetes version. Flyte does not constrain the provider or how you stand the cluster up — managed offerings (EKS, GKE, AKS), self-managed clusters, and on-prem all work.

Relational database

Flyte stores its persistent records in PostgreSQL (12 or newer). The binary reads a single database configuration, rendered by the chart under runs.database from your configuration.database values. Provision a database and a user before installing; the chart can create the database password Secret for you, or you can mount it from your own secret manager.

Object store

Flyte uses an object store to hold task inputs/outputs, metadata, and uploaded data. The chart supports S3, GCS, and Azure Blob Storage. You need at least one bucket, and the identity Flyte runs as needs these minimum permissions on it:

• GetObject
• PutObject
• ListBucket
• DeleteObject

Configure it as metadataContainer — Flyte stores everything (metadata, task inputs/outputs, and uploads) in that one bucket.

Optional dependencies

Flyte runs without these, but integrates with them when present.

Ingress controller

To expose Flyte beyond kubectl port-forward, you need an ingress controller installed in the cluster: the chart creates a standard Kubernetes Ingress resource, but a controller has to reconcile it into an actual load balancer.

On a managed cloud you don’t need to run your own controller — each cloud has a native one that reconciles the Ingress and provisions the cloud’s own load balancer:

DNS

For anything beyond local testing, point a DNS record at your ingress host so clients and the console reach Flyte at a stable address instead of localhost.

SSL/TLS

Use a valid certificate to secure traffic between clients and Flyte. On AWS this is typically an ACM certificate attached to the ALB; elsewhere it is a TLS Secret referenced from the Ingress.

Container images

The chart deploys two images, configurable under deployment.image and console.image. You normally don’t need to set these — the chart ships with working defaults:

When you’re ready, continue to the Kind deployment to try Flyte on a kind cluster, or the AWS deployment guide for a real deployment.