Skip to main content
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:
SectionPurpose
serverHTTP/gRPC port, TLS, CORS settings
authOIDC/OAuth2 authentication configuration
databasePostgreSQL connection
storageObject store backend (stow config)
cluster_resourcesProject/domain namespace templates
notificationsEmail and Slack notifications
domainsDomain definitions for multi-tenancy
schedulerScheduler settings
remoteDataSigned URL configuration

​
FlytePropeller config

FlytePropeller is the Kubernetes controller that drives workflow execution.
SectionPurpose
propellerWorker concurrency, GC intervals, leader election
pluginsPlugin-specific config (k8s, spark, ray, etc.)
tasksTask plugin registration and defaults
storageSame stow config as Admin
adminAdmin endpoint for reporting status
catalog-cacheDataCatalog endpoint for caching

​
DataCatalog config

SectionPurpose
datacataloggRPC port, storage path for artifact metadata
databaseSame PostgreSQL connection
storageSame 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

Build docs developers (and LLMs) love

Get started for freeTalk to us