Flyte 2: A Python-First Orchestrator That Still Needs Its Backend

What Flyte 2 Actually Does Differently

Flyte 2 is the new major version of the Flyte orchestration framework, used from pure Python. The README describes it as a way to reliably orchestrate ML pipelines, models, and agents at scale. The key shift is visible in the example: tasks are defined as plain Python functions decorated with @env.task, and you call them with await calculate.aio(num). That means the orchestration logic lives inside your Python process, not in a separate YAML or DSL. This is a fundamental change from Flyte 1, which relied on a Kubernetes backend and a more rigid workflow specification. For developers who already live in Python notebooks and scripts, this lowers the barrier to entry. You do not need to learn a new workflow language; you write async Python and let Flyte handle durability.

The Mechanism: TaskEnvironment and Async Execution

The core abstraction is the TaskEnvironment. You create one with a name and a container image, then define tasks inside it. The image is built from a Debian base with a specified Python version, and you can add pip packages. This environment is the unit of execution: each task runs in that image, which gives you reproducibility across local and remote runs. The example shows asyncio.gather to run multiple task invocations concurrently, and the run object holds the result. The serving path uses FastAPIAppEnvironment, which wraps a FastAPI app and exposes it via flyte.serve. This suggests that Flyte 2 treats model serving as a first-class citizen, not an afterthought. The CLI mirrors the Python API: flyte run hello.py main --numbers '[1,2,3]' does the same thing as python hello.py. That symmetry is useful for quick tests and for production where you might not want to write a Python entrypoint.

Installation and First Run: Real Commands

Installation is straightforward with uv: uv pip install flyte. For the terminal UI, you add the extra: uv pip install flyte[tui]. The README shows only the uv form; the package is published on PyPI as flyte. After installation, you write a Python file with the task environment and run it. The example uses flyte.init() before calling flyte.run, which presumably initializes the local runtime. For serving, you call flyte.init_from_config() and then flyte.serve(env). The CLI equivalents are flyte run and flyte serve. There is no mention of configuration files or environment variables in the README, so the init functions likely read defaults or a local config that is not documented here. That is a gap for anyone trying to set up a non-default environment.

The Missing Backend: A Critical Limitation

The most significant limitation is that the open source backend for Flyte 2 is coming soon, not here. The README states that the repository will contain the Kubernetes-native backend infrastructure for deploying Flyte 2 as a distributed, multi-node service; the README describes that backend as coming soon. There is a BACKEND_README in docs/ that covers the current state of the backend, protocol buffer definitions, and contribution guide. The Python SDK lives in the separate flyte-sdk repository; this repository is primarily Go backend code (manager/, executor/, runs/, charts/), and the README does not yet present it as a way to deploy a production cluster. For production, the README points to Union.ai, which is a commercial offering. That is a hard constraint: if you need multi-node orchestration today, you either pay for Union or wait. This is not a minor gap; it is the core of what an orchestrator is supposed to do.

Local Development Experience and the TUI

The README highlights a TUI for local development, installed via flyte[tui]. This suggests a focus on developer ergonomics. The README links to a YouTube video of it, and the feature itself is a differentiator from plain Python scripts. The Devbox option is another path: a local environment that you can run to try Flyte 2. There is also a GitHub Codespaces template. These options lower the friction for evaluation. However, the TUI is an extra, not core, and the README does not describe what it shows. If you are evaluating, you will need to install it and see for yourself. The local experience seems polished, but without the backend, it is only a single-node playground.

Licensing and Maintenance Signals

Flyte is a Graduated project of the LF AI & Data Foundation, which is a neutral governance signal. The license is Apache-2.0, which is permissive for commercial use and modification. The repository is actively maintained: the last push was on 2026-11-02, and releases are frequent: v2.0.51 on 2026-10-08, v2.0.52 on 2026-10-21 and v2.0.53 on 2026-10-27. That cadence suggests ongoing development, but note that the version numbers are in the 2.0.x range, which is still early. The README explicitly says Flyte 1 is now maintained on the master branch, so there is a split: Flyte 1 is stable, Flyte 2 is the future. For maintainers, this means you have to choose which branch to follow. The upgrade cost from Flyte 1 to Flyte 2 is not documented in this README, but given the complete rewrite of the API, it is likely significant. You cannot assume your Flyte 1 workflows will port over.

Alternatives and the Trade-Off in Approach

The natural alternative to Flyte 2 is Prefect or Dagster, both of which offer Python-native orchestration with a maintained open source backend. The difference in approach: Prefect and Dagster run a server that schedules and tracks tasks, and they have had production backends for years. Flyte 2 is betting on a pure Python client model where the orchestration is embedded in your code, which can be simpler for local development but requires a backend to scale. Another alternative is the original Flyte 1, which is on the master branch and has a Kubernetes backend, but it uses a different task and workflow API. If you need Kubernetes-native scheduling today, Flyte 1 is a proven option, but you will not get the new asyncio model. The trade-off is between a mature backend with an older API and a new API with a pending backend.

Who Should Adopt It Now and What to Verify

For a team building ML pipelines in Python and wanting a durable runtime, Flyte 2's local model is attractive. You can prototype with asyncio and the TUI without a cluster. But for production, you must wait for the open source backend or use Union.ai. The README does not give a timeline for the backend, so verify that before committing. Also check the flyte-sdk repository for the full SDK features, because this README only shows a small slice. The FastAPIAppEnvironment is promising for model serving, but it requires you to build a custom image with your dependencies, so verify that your serving stack fits. The CLI is a plus, but it is not documented in depth here. Start with the Devbox or Codespaces to test the local experience, then decide if the backend gap is acceptable.

Editorial conclusion

Flyte 2 is for Python developers who want a durable, asyncio-native orchestration layer for ML pipelines, model serving, and agent workflows, and who are comfortable running local experiments until the open source backend lands. Teams that need multi-node production orchestration today should not adopt this repository yet; they should either use the Union.ai backend or stick with Flyte 1 on the master branch. Before adopting, verify the backend release timeline, check that your Python version matches the SDK requirements, and confirm that the FastAPIAppEnvironment serving model fits your deployment target. The Python SDK lives in the separate flyte-sdk repository, and this repository's value depends on the backend that is still coming soon.

Frequently asked questions

Official sources

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