Flyte 2: a Python-first orchestrator for ML pipelines, with the backend still pending

What Flyte 2 solves, and for whom

Flyte 2 is aimed at Python teams that have outgrown a single machine but do not want to hand-write Kubernetes manifests for every pipeline step. The README describes the goal as reliably orchestrating ML pipelines, models, and agents at scale, in pure Python. The unit of work is a plain Python function decorated with @env.task, and the environment around it declares the container image, so the distance between a local script and a distributed run is mostly configuration rather than a rewrite.

The audience is narrow but clear. If your pipeline is a chain of Python functions with typed inputs and outputs, and you want each step to run in its own image with retries handled by a control plane, Flyte 2 is designed for that shape. If your work is a single long-running process, or you are orchestrating across languages where Python is a minority, the Python-first design is a mismatch rather than a feature. The README also positions agents and model serving alongside batch pipelines, which suggests the intended scope is broader than classic batch DAGs.

TaskEnvironment: how the mechanism is wired

The core abstraction is flyte.TaskEnvironment. In the README example, an environment is created with a name and an image built from flyte.Image.from_debian_base(python_version=(3, 12)). Tasks are then registered by decorating functions with @env.task. Because the decorator is bound to the environment, the image and dependency set travel with the task rather than being attached later at deploy time.

Two details in the example are worth noticing. First, tasks can be async, and the README shows main gathering results with asyncio.gather over calculate.aio(num) calls. The .aio suffix is the async invocation form of a task, so a task defined as a sync function can still be awaited inside an async task. Second, the entrypoint is explicitly guarded: flyte.init() sets up the client, flyte.run(main, numbers=list(range(10))) submits the workflow, and run.result reads the output. That is a local-first flow. The same file can be executed with python hello.py or submitted through the CLI, which the README shows as flyte run hello.py main --numbers '[1,2,3]'.

The repository itself is the Go side of that contract. The top-level layout includes manager, runs, executor, flytecopilot, dataproxy, cache_service, secret, events, actions, and flyteidl2, and the Makefile has build targets for manager, runs, and executor. The Dockerfile compiles a flyte binary from ./manager/cmd/ and a flyte-copilot binary, and copies the copilot to /bin/flyte-copilot because, as a comment in the Dockerfile states, flyteplugins invokes it at that exact path. Protobuf generation is configured for Go, Python, Rust, and TypeScript (buf.gen.go.yaml, buf.gen.python.yaml, buf.gen.rust.yaml, buf.gen.ts.yaml), which tells you the service surface is not Python-only even though the authoring surface is.

Installing Flyte 2 and running the first task

The README gives a single install command for the SDK. It uses uv, so you need uv available or an equivalent pip invocation.

uv pip install flyte

For the terminal UI that the README calls a rich local development experience, install the extra:

uv pip install flyte[tui]

The README points to the flyte-sdk repository for the full SDK and development tools, so treat the package above as the entry point rather than the whole toolkit.

A first real use is the hello-world file from the README. Save it as hello.py. It defines an environment with a Debian base image at Python 3.12, one arithmetic task, and an async task that fans out over a list.

import asyncio
import flyte

env = flyte.TaskEnvironment(
    name="hello_world",
    image=flyte.Image.from_debian_base(python_version=(3, 12)),
)

@env.task
def calculate(x: int) -> int:
    return x * 2 + 5

@env.task
async def main(numbers: list[int]) -> float:
    results = await asyncio.gather(*[
        calculate.aio(num) for num in numbers
    ])
    return sum(results) / len(results)

if __name__ == "__main__":
    flyte.init()
    run = flyte.run(main, numbers=list(range(10)))
    print(f"Result: {run.result}")

Run it directly with the Python interpreter:

python hello.py

Or submit the same task through the CLI, passing the argument list as a JSON string:

flyte run hello.py main --numbers '[1,2,3]'

The README presents these two paths as equivalent. What you should see is the printed average from run.result in the Python case, and the CLI reporting the run for the submitted task. If you want a hosted environment instead of a local process, the README links a Devbox guide and a GitHub Codespaces quickstart at codespaces.new/flyteorg/flyte-devbox-codespace?quickstart=1. The README does not document what the local flow persists between runs, so do not assume run history survives a restart of whatever you started locally.

Serving a model from the same file

Flyte 2 also covers long-running services, which is a different lifecycle from a batch task. The README shows a FastAPI app wrapped in flyte.app.extras.FastAPIAppEnvironment. The environment takes the app object, a name, and an image that installs fastapi and uvicorn through with_pip_packages.

from fastapi import FastAPI
import flyte
from flyte.app.extras import FastAPIAppEnvironment

app = FastAPI()
env = FastAPIAppEnvironment(
    name="my-model",
    app=app,
    image=flyte.Image.from_debian_base(python_version=(3, 12)).with_pip_packages(
        "fastapi", "uvicorn"
    ),
)

@app.get("/predict")
async def predict(x: float) -> dict:
    return {"result": x * 2 + 5}

The submission step differs from the task example in one respect: it calls flyte.init_from_config() rather than flyte.init(), then flyte.serve(env). The CLI equivalent is flyte serve serving.py env. The use of a config-based initializer for serving, versus the argument-free initializer for local task runs, is the kind of detail worth copying exactly rather than guessing at. The README does not describe how the served app is exposed, scaled, or health-checked, so those are open questions you would resolve against the SDK reference rather than this repository.

The backend gap is the real limitation

The most consequential sentence in the README is that the open source backend for Flyte 2 is coming soon. This repository is described as the place that will contain the Kubernetes-native backend for deploying Flyte 2 as a distributed, multi-node service, and the README points readers to docs/BACKEND_README.md for the current state. For anyone who reads Flyte 2 as a self-hosted alternative to a managed orchestrator, that is the fact that decides the evaluation. The README states plainly that if you need an enterprise-ready, production-grade backend for Flyte 2 today, it is available on Union.ai.

There is a second boundary. Flyte 1 is not gone; the README says it now lives on the master branch, and the default branch here is main. That means two major versions are maintained in parallel in the same repository, and any issue, pull request, or documentation page you find may belong to either. The repository layout supports the split: the Dockerfile builds the flyte manager binary and the copilot, and the Makefile targets manager, runs, and executor, none of which map to the Python authoring surface a new user touches first. If you are evaluating Flyte 2 as a Python library, most of what you will read in this repository is about a backend you may not be running.

How Flyte 2 differs from Airflow and Kubeflow Pipelines

The closest comparison for a Python team is Airflow. Airflow schedules tasks defined as operators or decorated functions, and its scheduler, metadata database, and webserver are components you deploy and operate. The DAG is a scheduling artifact, and containerization is something you opt into per operator. Flyte 2 inverts that: the container image is part of the environment declaration, and the task is a typed Python function whose inputs and outputs are part of the interface. There is no separate DAG file in the README example; the call graph in main is the workflow.

Kubeflow Pipelines is the other obvious reference point, and the repository itself hints at the relationship: go.mod lists github.com/kubeflow/training-operator. KFP is Kubernetes-first, with pipelines compiled to a spec and submitted to a cluster. Flyte 2 starts from a local runnable script and adds the cluster layer through the backend that is not yet released here. That ordering matters. It makes the first ten minutes easier and the production deployment question harder, at least until the backend lands. If you already run KFP and your team is comfortable in that model, Flyte 2 asks you to move the authoring surface into Python and wait on the self-hosted control plane.

Licence, maintenance, and upgrade cost

Flyte is licensed under Apache-2.0, with the LICENSE file at the repository root. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations for redistributed modified files. This is not legal advice; if you plan to redistribute a modified flyte binary, read the licence text and your own counsel's guidance rather than this summary.

The project is a Graduated project of the LF AI & Data Foundation, per the README, and the repository is not archived. The last push was on 2026-08-26, and the most recent release listed is v2.0.44 on the same date, following v2.0.43 on 2026-08-21 and v2.0.42 on 2026-08-15. That cadence is fast, and fast release cadence is itself an upgrade cost: pinning a version and reading the release notes before moving is the practical posture. The parallel maintenance of Flyte 1 on master means you should also confirm which version a given fix targets before you plan an upgrade around it.

Editorial conclusion

Adopt Flyte 2 if your team writes Python, needs typed task graphs with retries and container images declared in code, and can run the Devbox locally or use Union.ai for a managed backend. Do not adopt it if you need a self-hosted, multi-node Kubernetes control plane today: the README states the open source backend is coming soon and points to Union.ai for a production-grade backend. Before committing, verify that the flyte-sdk repository covers the features you need, since this repository is the Go backend and its README directs SDK questions there, and confirm whether the backend under docs/BACKEND_README.md is at a state you can deploy.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes