24k stars · Apache-2.0 · 3.8.8 (2026-10-06) · Track this in Scout
Adds scheduling, retries and a run history to Python functions you already have.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You put a @task decorator on a function and a @flow decorator on the function that calls it. That is the whole change to your code. Running the flow now reports every task's start, finish and result to a server, which you can run yourself with prefect server start. Failed tasks retry on a policy you set, with a delay between attempts. Flows can run on a schedule, on a cron expression, or when triggered. Tasks that do not depend on each other run concurrently, and results can be cached so a re-run skips work that already succeeded. The web interface shows each run as a timeline with logs and the exact error. Deployments describe where a flow runs — locally, in a container, or on a worker pool. It is Python only, it does not move or transform data by itself, and the self-hosted server has no built-in user accounts or permissions, which the project states plainly.
Why it matters
Who it suits. Anyone with a handful of Python jobs on a timer who currently has no idea whether last night's run worked. Report generation, data refreshes, backups that are really scripts, anything where silence looks the same as success. It suits people who want to keep writing ordinary Python rather than learning a pipeline description language. Skip it if one cron line and an email on failure already tell you what you need, because this is a server to run and keep running.
Verdict. Worth an afternoon, and the appeal is how little it asks of your existing code — two decorators, and you can take them off again. That is a real difference from the heavier orchestrators, where adopting the tool means rewriting your job as the tool's object. Version 3.8.8 landed on 6 October 2026. The caution is honest and comes from the project itself: run the open server behind something that handles authentication, because it does not do that for you. apache/airflow is the industrial choice with the largest ecosystem and the steepest start, and dagster-io/dagster is the one to look at if you think in terms of the datasets being produced rather than the steps being run. Edition 45 covered kestra-io/kestra for the same problem described in YAML instead of Python.
- Two decorators and your existing functions are orchestrated. Reversible in a minute.
- The run history and the error view answer "did it run, and what broke" immediately.
- Retries, caching and concurrency are configuration rather than code.
- The self-hosted server ships with no accounts or permissions. Put it behind a proxy that has them.
- It is a server and a database to keep alive, which is more to maintain than a cron line.
- Python only, and the major versions have broken things before, so read the upgrade notes.
- apache/airflow
The long-established platform for the same job, with the widest set of connectors and a much larger setup; workflows are written as code but in Airflow's own shape.
Track this in Scout - dagster-io/dagster
Organised around the data assets being produced and their lineage, rather than around the steps that run.
Track this in Scout 
kestra-io/kestraThe same problem described in YAML files, so the jobs need not be Python at all; covered in Edition 45.
Track this in Scout
python3 -m venv venv source venv/bin/activate pip install prefect prefect server start # leave this running; the interface is on port 4200
