Flyte 1 vs. Flyte 2
Flyte 2 is a massive architectural upgrade to Flyte 1, delivering higher scale, higher performance, and higher durability with simple migration.
Compare Features
Flyte 1 was built for a world of linear data pipelines. Flyte 2 is built for the world you're actually operating in now: durable compute-intensive jobs, dynamic agentic workflows, and production scale. Same open-source commitment, upgraded runtime underneath.
Scale & Throughput
Flyte 2 delivers greater scale via improved fanout and control flow.
Authoring & Workflow Semantics
Flyte 2 introduces improvements designed to make authoring much easier and enable dynamic, agent-native workflows.
Durability & Failure Recovery
Flyte 2 recovers from the actual failure modes that break production Al/ML workloads, without you writing custom
Inference & Agents
Flyte 2 extends inference to include batch + realtime serving.
Migrating from Flyte 1
If you're running Flyte 1 in production, we’ve created resources to make the upgrade easy.
Migration Hub
See our full collection of resources, including the step-by-step Migration Guide, skills, Flyte 1 support sunset info, and virtual office hours.
1:1 Migration Consultation
(limited availability)
Get 30 minutes with a Union.ai engineer to walk through your specific migration, free.
Frequently asked questions
Where can I find help migrating from Flyte 1 to Flyte 2?
Start with the Migration Hub for all resources or go straight to the Migration Guide for step-by-step instructions and the full API-level mapping.
Do I need to rewrite my Flyte 1 workflows?
No. The Python task and workflow model carries forward. Most migration work is mechanical, updating decorators and config patterns, not a rewrite of your workflow logic.
Is Flyte 1 deprecated now that Flyte 2 is out?
Flyte 1 will continue to receive security patches in accordance with the published sunset schedule on the Migration Hub, after which it will be end of life.
Does Flyte 2 require new infrastructure to run?
No. The deployment model is unchanged, same Helm, Postgres, ingress, and IAM setup. Flyte 2 is now validated for single-cluster production at GA, so if you're already running Flyte 1 this way, it's an upgrade in place.
What changed between flytekit and the Flyte 2 SDK?
Task configuration (image, hardware resources) now lives in a `TaskEnvironment` object instead of the task decorator. Workflows are authored as tasks calling tasks directly via `@env.task`, one decorator instead of two. `map_task` maps to `flyte.map` or `asyncio.gather`, and `ImageSpec` maps to `flyte.Image`. These are the breaking changes to plan for, and the Migration Guide has the full API-level mapping.
Do I need to change my @task and @workflow decorators for Flyte 2?
Yes and it’s a straightforward update. `@workflow` and `@task` become `@env.task` decorators defined within a `TaskEnvironment`. The Migration Guide takes you through this.
What does single-cluster production support for Flyte 2 mean?
It's the GA milestone that completes the path from local devbox development to full production scale in one open-source platform. You build and test locally, then run the same environment in production with no architectural changes.
