# 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:

| Component | Responsibility |
|---|---|
| Runs service | Accepts and stores run/task/workflow requests; owns the database. |
| Executor | Reconciles task runs onto Kubernetes. |
| Data proxy | Issues signed URLs for uploading and downloading data to the object store. |
| App service | Manages apps — long-running serving deployments — and their lifecycle. |
| Action service | Manages actions — short-lived task runs — and their lifecycle. |
| Cache service | Manages the cache for task runs and actions. |

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:

```mermaid
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](https://connectrpc.com/) **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](https://kubernetes.io/releases/version-skew-policy/#supported-versions).
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:

| Environment | Ingress controller | Provisions |
|---|---|---|
| AWS (EKS) | [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) | Application Load Balancer (ALB) |
| GCP (GKE) | [GKE Ingress](https://cloud.google.com/kubernetes-engine/docs/concepts/ingress) (built in) | Google Cloud HTTP(S) Load Balancer |
| Azure (AKS) | [Application Gateway Ingress Controller (AGIC)](https://learn.microsoft.com/azure/application-gateway/ingress-controller-overview) | Azure Application Gateway |
| On-prem / any | [Contour](https://projectcontour.io/) or [Traefik](https://traefik.io/) (with MetalLB or a NodePort for the external address) | self-managed |

### 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:

| Image | Default repository |
|---|---|
| Flyte binary | `cr.flyte.org/flyteorg/flyte-binary-v2` |
| Console | `ghcr.io/unionai-oss/flyteconsole-v2` |

When you're ready, continue to the
[Kind deployment](https://www.union.ai/docs/v2/flyte/oss-deployment/overview/kind-deployment/_index) to try Flyte on a kind cluster,
or the [AWS deployment](https://www.union.ai/docs/v2/flyte/oss-deployment/overview/aws-deployment) guide for a real deployment.

---
**Source**: https://github.com/unionai/unionai-docs/blob/main/content/oss-deployment/overview.md
**HTML**: https://www.union.ai/docs/v2/flyte/oss-deployment/overview/