Orchestration tools grew until the tool became the job. We think that's backwards. This is the reasoning behind Fast-Flow — and an honest note on when you shouldn't use it.
Somewhere along the way, running a Python script on a schedule started requiring a message broker, a metadata database, a scheduler process, a webserver, a fleet of workers, and a CI pipeline that bakes Docker images for ten minutes so you can change one line of code.
That stack makes sense at a certain scale. Most teams never reach it. They pay the operational tax anyway — because "that's what you use."
"We made deployment as boring as possible so you can focus on the exciting part: your code."
Not a DAG. Not an asset graph. Not YAML. A pipeline is a main.py in a folder. If it runs on your laptop, it runs in the orchestrator — same code, same environment, reproduced with one uv command.
Every abstraction between "I wrote a script" and "it runs in production" must justify itself. Decorators, operators, XComs, sensors — for a handful of scripts, none of them do.
The slowest part of most orchestration setups isn't execution — it's shipping. Build image, push to registry, roll workers, wait. Fast-Flow deletes the whole step: a generic worker plus a shared uv cache means new dependencies resolve once and hardlink in milliseconds forever after. Changing requirements.txt is a git commit, not a build pipeline.
The repository is the single source of truth — code, dependencies, resource limits, schedules. What you see in the UI is what's in Git, always. Who raised the memory limit? Who bumped prophet? Your git log answers. Rollback is git revert, not an image archaeology expedition.
Shared worker environments are where dependency hell lives. Every Fast-Flow run gets a disposable sandbox — an ephemeral container or a Kubernetes Job pod — with hard CPU and memory limits, then it's destroyed. One pipeline can never poison another. And the orchestrator never touches the Docker socket directly: a filtering proxy in Docker mode, plain RBAC on Kubernetes.
Fast-Flow is deliberately narrow. If you need data-asset lineage, use Dagster. If you need a richer Python orchestration engine with flexible workers, use Prefect. If you're wiring dozens of systems together with event triggers, use Kestra. If you're an enterprise with a platform team and a thousand DAGs — Airflow exists for you.
But if your problem is "a handful of Python scripts, and Airflow is overkill" — that trade is the whole point. We traded breadth for a mental model you can hold in your head and an operational footprint of one process.