// the find
flyteorg/flyte
Dynamic, resilient AI orchestration. Coordinate data, models, and compute as you build AI workflows.
Flyte is a Kubernetes-native workflow orchestration platform for ML pipelines and AI agents, backed by Union.ai and graduated under the LF AI & Data Foundation. The repo is mid-transition from v1 to v2, which rewrites the Python SDK to use a cleaner decorator-based async API. Aimed at ML/MLOps teams who already run Kubernetes and need reproducible, auditable pipeline runs at scale.
The v2 Python API is a genuine improvement — decorator-based task definition with native async/await is far cleaner than the old flytekit approach, and the type system carrying through task boundaries catches a class of errors before execution. The caching layer is real infrastructure, not an afterthought: there's a dedicated cache_service with reservation semantics to prevent redundant parallel evaluations of the same task. It's a Graduated LF project with real production deployments, so the operational lessons are baked in — things like the separate executor CRD and the dataproxy for large literal handling exist because people hit those limits. The devbox Helm chart bundling k3d, Traefik, and an embedded Postgres makes local development actually runnable without a cloud account.
The open-source backend for Flyte 2 does not exist yet — the README buries this in one paragraph: 'coming soon.' If you install the v2 SDK today and want to run it distributed, you need Union.ai. The nice async Python API is effectively demo-ware for self-hosters right now. The v1/v2 split across branches (v1 on master, v2 on main) means the community knowledge base, Stack Overflow answers, and existing integrations all target a version that's now in maintenance mode. The Kubernetes requirement is a hard floor — this is not for teams without a k8s cluster and someone who knows how to operate it; the Helm chart alone has 15+ configurable components. Observability into why a specific task failed requires digging through multiple layers: PropellerManager logs, executor CRD status, and pod logs, which is manageable once you know the mental model but brutal during initial debugging.