Configure Airflow 3 DAG bundles to version and source DAGs from multiple repositories
domain: data-engineering · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Set [dag_processor] dag_bundle_config_list in airflow.cfg to a list of bundle definitions, each with name, classpath, and kwargs.
Use airflow.dag_processing.bundles.local.LocalDagBundle for the default filesystem-based bundle if you're not moving to a source-controlled bundle yet — note it has no versioning.
Switch a bundle to airflow.providers.git.bundles.git.GitDagBundle (or an S3/GCS provider bundle class) to source DAGs from a separate repo with real version tracking.
Never put repo credentials directly in a bundle's kwargs, since those are exposed via the Config API — register a Connection and reference it instead.
Understand that every DAG run records which bundle version (e.g. git commit) produced it — this is what "DAG versioning" refers to in Airflow 3, tied to the bundle rather than a separate DAG-file mechanism.
Use disable_bundle_versioning / rerun_with_latest_version to control whether a manual rerun replays against the original bundle version or picks up the latest.
Known gotchas
Bundle kwargs are exposed through the Config API — a git token pasted directly into dag_bundle_config_list is effectively readable by anyone with API config access.
LocalDagBundle has no versioning at all — if you need runs pinned to a specific DAG version for backfills or reruns, you must move to a versioned bundle type (git/S3/GCS), not just enable multi-bundle config.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?