Multi-Team Apache Airflow:
A Customer-Driven Journey

Airflow Summit · Austin, TX · Aug 31 – Sep 2, 2026

One Airflow, Many Teams

How do you give every team its own Airflow,
without running Airflow for every team?

Historically, Two Compromises

Airflow for every team

+ Full isolation between teams

+ Upgrade environments individually

– Expensive: many databases, schedulers, …

– Management burden grows per environment

One Airflow for everyone

A B C D E

+ One upgrade path, simple management

+ Cheap: shared infrastructure

– No isolation: noisy neighbours

– Everyone sees (and can break) everything

Working Backwards

Airflow Summit talks in the last 3 years relating to
multi-team/tenant platforms

30%

Airflow Survey respondents over the last 4 years consistently want
multi-tenancy as a new feature

Introducing: Multi-Team (AIP-67)

What is it?

It is NOT: a hard, “bullet proof” multi-tenancy (like AWS cloud isolation)

It IS: isolation for co-operative teams within an organization

Share the control plane, isolate the execution / data plane

The Core Tenets of Multi-Team

Shared Infrastructure: keep costs down and management simple
Execution Isolation: entirely separate execution paths per team (if desired)
Security: team-specific Connections, Variables, Secrets, etc.
UI Focus: teams only see their Dags, Tasks, Connections, etc.
Flexibility: mix’n’match: team namespaces when required, global when it’s not
Opt In: no overhead when not enabled

Architecture

Team-based Metrics (new in 3.3)

Operational metrics now include a team_name tag/dimension, so you can create per team dashboards:

ti.finish count=1 team_name=team_a

executor.open_slots gauge=12 team_name=team_b

dagrun.duration.success timer=134s (this dagrun is from a global namespace, no team_name tag)

Covers: triggerer, executors, scheduler & pools, dag runs, task instances, dag processing, callbacks
Requires a tag-aware backend: StatsD with tagging (Datadog / InfluxDB dialects) or OpenTelemetry
When Multi-Team is disabled, metrics are emitted exactly as before

Cross-Team Asset Events (new in 3.3)

The scenario. Team A’s Dag emits events for the clickstream asset; Team B’s Dag schedules on it. In multi-team mode, asset events are filtered by team. Let’s see what happens.

1) Default: no cross-team events. A consumer only receives events from Dags in its own team (or global, teamless Dags). Team A’s event hits the team boundary, and Team B’s run is never triggered.

2) Consumer opts in with producer_teams. Team B declares who it trusts on its asset definition: AssetAccessControl(producer_teams=["team_a"]). Events from Team A now flow through and trigger the run.

3) Producer can still say no with consumer_teams. On the producing task’s outlet, consumer_teams=[...] restricts who may receive its events. Both checks must pass (AND logic). Team B isn’t listed, so it’s blocked again despite its opt-in.

Misc. Architecture Notes

Enable with [core] multi_team = True; manage teams with the new airflow teams CLI (create / list / delete)
Dag IDs, Team names, Variable keys and Connection IDs must be unique across teams: think global S3 bucket names; prefix with team names
This is an advanced setup, meant for platform engineers at medium-to-large companies with many teams.

Demo Setup

Global

Executor: LocalExecutor

User: admin (access to all teams)

team1

Executor: LocalExecutor

User: user1

team2

Executor: CeleryExecutor

User: user2


export AIRFLOW__CORE__MULTI_TEAM="True"
export AIRFLOW__DAG_PROCESSOR__DAG_BUNDLE_CONFIG_LIST='[
 {
   "name": "global",
   "classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
   "kwargs": { "path": "/files/team-dags/global" }
 },
 {
   "name": "dags-folder1",
   "classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
   "kwargs": { "path": "/files/team-dags/team1" },
   "team_name": "team1"
 },
 {
   "name": "dags-folder2",
   "classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
   "kwargs": { "path": "/files/team-dags/team2" },
   "team_name": "team2"
 }
]'
export AIRFLOW__CORE__SIMPLE_AUTH_MANAGER_USERS="admin:admin,user1:op:team1,user2:op:team2"

export AIRFLOW__CORE__EXECUTOR="LocalExecutor;team1=LocalExecutor;team2=CeleryExecutor"