Configuration overview

Understand how Flyte’s configuration system works — config files, Helm values, and environment variable overrides.

Flyte is configured through a layered system of YAML config files. Each service (FlyteAdmin, FlytePropeller, DataCatalog) reads from one or more config files at startup. When deploying with Helm, config is rendered into Kubernetes ConfigMaps.

Config file format

Flyte config files are standard YAML. Each top-level key maps to a named configuration section registered by a component. Multiple sections can live in a single file, or be split across files in a directory.

Flyte reads all *.yaml files under the path specified by --config (default: /etc/flyte/config/). The files are merged, with later files overriding earlier ones.

# /etc/flyte/config/admin.yaml
admin:
  endpoint: dns:///flyteadmin:81
  insecure: true

# /etc/flyte/config/db.yaml
database:
  postgres:
    username: postgres
    password: postgres
    host: postgres.flyte.svc.cluster.local
    port: 5432
    dbname: flyteadmin
    options: sslmode=disable

Config sections by service

FlyteAdmin config

FlyteAdmin reads --config files that can contain the following top-level sections:

Section	Purpose
server	HTTP/gRPC port, TLS, CORS settings
auth	OIDC/OAuth2 authentication configuration
database	PostgreSQL connection
storage	Object store backend (stow config)
cluster_resources	Project/domain namespace templates
notifications	Email and Slack notifications
domains	Domain definitions for multi-tenancy
scheduler	Scheduler settings
remoteData	Signed URL configuration

FlytePropeller config

FlytePropeller is the Kubernetes controller that drives workflow execution.

Section	Purpose
propeller	Worker concurrency, GC intervals, leader election
plugins	Plugin-specific config (k8s, spark, ray, etc.)
tasks	Task plugin registration and defaults
storage	Same stow config as Admin
admin	Admin endpoint for reporting status
catalog-cache	DataCatalog endpoint for caching

DataCatalog config

Section	Purpose
datacatalog	gRPC port, storage path for artifact metadata
database	Same PostgreSQL connection
storage	Same stow config

Helm values and the inline escape hatch

When using the flyte-binary chart, most config is set through the structured configuration.* values. For settings that do not have a dedicated Helm value, use the configuration.inline key to pass raw Flyte config YAML:

# values.yaml
configuration:
  database:
    host: my-rds-instance.us-east-1.rds.amazonaws.com
    dbname: flyteadmin
  inline:
    # Any raw Flyte config goes here
    propeller:
      workers: 40
      gc-interval: "30m"
    plugins:
      k8s:
        default-labels:
          team: ml-platform

For the flyte-core chart, config is rendered under the configmap key:

configmap:
  adminServer:
    server:
      httpPort: 8088
      grpc:
        port: 8089
      security:
        secure: false
        useAuth: false
        allowCors: true
        allowedOrigins:
          - "*"

Environment variable overrides

Every Flyte config key can be overridden with an environment variable using the following pattern:

FLYTE_<SECTION>_<KEY>=value

For nested keys, use underscores:

export FLYTE_DATABASE_POSTGRES_HOST=my-db-host
export FLYTE_DATABASE_POSTGRES_PASSWORD=secret
export FLYTE_STORAGE_STOW_CONFIG_REGION=us-east-1

Environment variable overrides take precedence over config files. This is useful for injecting secrets (e.g., database passwords) at runtime without storing them in ConfigMaps.

PodTemplate configuration

Starting with Flyte 1.4, you can use Kubernetes PodTemplate resources to define default pod configuration for all task pods. There are two types:

Compile-time PodTemplates

Defined inline in a @task decorator:

from kubernetes.client.models import V1PodSpec, V1Container, V1ResourceRequirements
from flytekit import task, PodTemplate

@task(
    pod_template=PodTemplate(
        primary_container_name="primary",
        pod_spec=V1PodSpec(
            containers=[
                V1Container(
                    name="primary",
                    resources=V1ResourceRequirements(
                        limits={"cpu": "2", "memory": "4Gi"}
                    ),
                ),
            ],
        )
    )
)
def heavy_task() -> int:
    ...

Runtime PodTemplates

Create a Kubernetes PodTemplate resource in the flyte namespace to apply defaults to all tasks in the cluster:

apiVersion: v1
kind: PodTemplate
metadata:
  name: flyte-template
  namespace: flyte
template:
  metadata:
    labels:
      team: ml-platform
  spec:
    containers:
      - name: default
        image: docker.io/rwgrim/docker-noop
    hostNetwork: false

To enable runtime PodTemplates, set the default-pod-template-name in the FlytePropeller k8s plugin config:

configuration:
  inline:
    plugins:
      k8s:
        default-pod-template-name: flyte-template

K8s plugin configuration

The K8s plugin config controls how Flyte constructs task pods:

configuration:
  inline:
    plugins:
      k8s:
        inject-finalizer: true
        default-env-vars:
          - MY_ENV_VAR: my-value
        default-labels:
          app: flyte-task
        default-annotations:
          iam.amazonaws.com/role: arn:aws:iam::123456:role/task-role
        co-pilot:
          image: "cr.flyte.org/flyteorg/flytecopilot:v0.0.15"
          start-timeout: "30s"

Configuration precedence

From lowest to highest priority:

1. Default values compiled into the binary
2. Config files in --config directory
3. configuration.inline values (via Helm)
4. Environment variable overrides