Skip to main content

Overview

Flyte 2 is a fundamental shift in how you build and orchestrate data and AI applications. It moves away from constrained domain-specific languages (DSLs) to pure Python. With Flyte 2, you write pipelines, serve models, and orchestrate agents exactly like you write any other Python code—because it is just Python.

The Problem: DSL Friction

Traditional orchestration tools often force you into a "DSL cage." You have to learn custom syntax for loops, conditionals, and error handling that doesn't behave like standard Python. This makes debugging hard, testing difficult, and local development a chore.

Flyte 2 solves this by letting you use standard Python constructs (for loops, if/else, try/except) directly. It handles the heavy lifting of containerization, resource allocation, and distributed execution behind the scenes.

Core Concepts: The Workshop Model

To understand Flyte 2, think of the Workshop Model:

  • TaskEnvironment: Think of this as a specialized workshop. It defines the infrastructure (Docker image, CPU/Memory/GPU resources, environment variables) needed to run your code.
  • Task: This is the job you perform in the workshop. It's a regular Python function decorated with @env.task.
  • Run: The execution of a task. When you call a task, Flyte ensures it runs in the correct environment, potentially on a remote cluster.
  • Action: A single step within a run. Every time a task is called or a function is traced, it creates an action that Flyte tracks and can checkpoint.

How it Works

  1. Define Environments: You create TaskEnvironment objects to specify the "where" and "how" of your execution.
  2. Decorate Functions: You use @env.task to mark functions that should run as managed Flyte tasks.
  3. Write Pure Python: Compose your logic using standard Python. Call tasks from other tasks, use asyncio for parallelism, and handle errors with try/except.
  4. Deploy or Run: Use the flyte CLI to run tasks locally or on a remote cluster, or deploy environments for production use.

Use Cases / Examples

1. Simple Data Processing

Define an environment and a task to perform a calculation.

import flyte

env = flyte.TaskEnvironment(
name="math-env",
resources=flyte.Resources(cpu=1, memory="512Mi")
)

@env.task
def add(x: int, y: int) -> int:
return x + y

# Run it locally or remotely
if __name__ == "__main__":
flyte.init()
result = flyte.run(add, x=10, y=20)
print(result.outputs)

2. Async Parallelism

Use standard asyncio to run multiple tasks in parallel without special "map" constructs.

import asyncio
import flyte

env = flyte.TaskEnvironment(name="parallel-env")

@env.task
async def process_item(item: int) -> int:
await asyncio.sleep(1)
return item * 2

@env.task
async def main(items: list[int]) -> list[int]:
# Standard asyncio.gather just works!
return await asyncio.gather(*[process_item(i) for i in items])

3. App Serving

Serve a FastAPI app as a first-class Flyte deployment.

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

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

@app.get("/greet/{name}")
async def greet(name: str):
return {"message": f"Hello, {name}!"}

4. Function-Level Checkpointing

Use @flyte.trace to checkpoint intermediate steps within a task, allowing for efficient recovery.

import flyte

@flyte.trace
def expensive_step(data: str) -> str:
# This result will be checkpointed
return data.upper()

@env.task
def my_workflow(input_data: str):
step1 = expensive_step(input_data)
# If the task fails here, it can resume from step1
return step1 + "_PROCESSED"

When to Use / When Not to Use

Use Flyte 2 When...Avoid Flyte 2 When...
You want to write complex logic in pure Python.You have very simple, linear scripts with no infra needs.
You need to manage diverse infra (GPUs, TPUs) easily.You are running everything on a single local machine.
You are building compound AI apps or agents.You prefer a strictly visual, drag-and-drop DAG builder.
You need first-class support for serving web apps.You only need a simple cron-job runner.

Integration / Stack Compatibility

  • Languages: Primary support for Python 3.10+.
  • Infrastructure: Works with Kubernetes, AWS, GCP, and Azure.
  • Frameworks: Native integrations for FastAPI, Streamlit, Ray, Spark, and PyTorch.
  • Tools: Built-in support for uv and poetry for dependency management.

Getting Started Pointers

  • [[LINK: Installation Guide]] — Get the flyte CLI and SDK installed.
  • [[LINK: First Task Tutorial]] — Write and run your first task in 5 minutes.
  • [[LINK: App Serving Guide]] — Learn how to deploy FastAPI or Streamlit apps.
  • [[LINK: Migration from Flyte 1]] — Moving from flytekit to the new SDK.

Limitations / Assumptions

  • Python-Centric: While Flyte itself is polyglot, this SDK is focused on providing the best possible Python experience.
  • Docker Dependency: Building images locally requires a Docker daemon.
  • Async First: To get the most out of parallelism, familiarity with Python's asyncio is recommended.

FAQ

Q: Is this a replacement for flytekit? A: Yes, this is the next-generation SDK (Flyte 2) designed to be more Pythonic and flexible than the original flytekit.

Q: Do I still need to define Workflows? A: No. In Flyte 2, "Workflows" are just tasks that call other tasks. There is no separate @workflow decorator required.

Q: How do I handle retries and caching? A: These are configured either at the TaskEnvironment level (as defaults) or directly in the @env.task decorator.

Q: Can I run this locally? A: Yes! flyte run works locally out of the box, and you can use flyte.init() to connect to a remote backend when you're ready.