// the find
astronomer/dag-factory
Construct Apache Airflow DAGs Declaratively via YAML configuration files
dag-factory lets you define Airflow DAGs in YAML instead of Python, handling the boilerplate of DAG construction at parse time. Maintained by Astronomer and recently updated for Airflow 3 compatibility. Useful for teams that have many structurally similar DAGs or want to keep pipeline definitions out of Python code.
- Airflow 3 support is already in place, and separate example sets for Airflow 2 vs 3 make the migration story clear rather than leaving users to guess about breaking changes.
- Surprisingly broad feature coverage: dynamic task mapping, TaskFlow API, KubernetesPodOperator, callbacks, timetables, assets/datasets, and custom operators all work from YAML — this isn't just basic BashOperator wrappers.
- The comparison examples (hackernews, pypi_stats) with side-by-side plain Airflow vs dag-factory YAML are genuinely useful for evaluating the tradeoff before committing.
- Test coverage is solid with unit tests, fixture YAML files, and integration test scripts separated from dev examples.
- YAML-as-code trades Python's type safety and IDE support for brevity; misconfigured keys silently get ignored or throw opaque KeyErrors at DAG parse time, which is painful to debug in a running Airflow instance.
- Complex dependency logic (branching, XCom-driven conditions, custom sensors) still requires dropping back to Python via `python_callable` or custom operators, meaning non-trivial DAGs end up as hybrid YAML+Python that's harder to follow than pure Python.
- Telemetry is baked in via a Scarf pixel and `telemetry.py` — opt-out requires setting an env var, and this is not prominently disclosed in the README, only in a separate PRIVACY_NOTICE.md.
- The 1.0 breaking changes are recent and the migration guide exists, but there's no deprecation period visible in the changelog — teams upgrading existing deployments will hit surprises.