Apache Airflow, engineered and operated for mission-critical pipelines

At the Airflow 3.0 launch, the project counted more than 30 million monthly downloads and 80,000 organizations, up from 25,000 in 2020 (Apache Airflow (opens in a new tab)). It now runs far more than ETL: in the State of Apache Airflow 2026 (opens in a new tab) report, drawn from 5,800+ practitioners, 32% of users run GenAI or MLOps workloads on it and 89% expect to use it for more revenue-generating or external solutions next year (Astronomer (opens in a new tab)). Meanwhile the platform itself has been rebuilt:

• check_circleYou're still on Airflow 2.x, or on a managed version your provider is retiring.
• check_circleThe scheduler lags, tasks sit queued, or DAG parsing slows as the estate grows.
• check_circleBusiness users discover failed pipelines before your team sees an alert.
• check_circleOne or two people hold all the Airflow knowledge.
• check_circleEnvironment costs grow faster than the workloads they run.
• check_circleSeveral teams share one deployment with no isolation between them.
• check_circleYou want to orchestrate LLM and agent workloads, but need audit trails and approvals first.

Airflow 3 is a re-architecture, so we run the move as an engineering program, not a version bump.

1. 1

   Inventory: DAGs, custom operators, plugins, providers, connections and the teams that own them.

2. 2

   Readiness scan: Ruff rules AIR301 and AIR302 flag breaking changes, AIR311 and AIR312 flag recommended updates, and airflow config update checks configuration (Apache Airflow upgrade guide (opens in a new tab)).

3. 3

   Step to 2.11 first: the final 2.x minor release surfaces deprecation warnings before the jump.

4. 4

   Refactor: move imports to the Task SDK and the standard provider, replace removed context variables and SubDAGs, move SLA checks to deadline alerts, and remove direct metadata database access from tasks.

5. 5

   Clean and rehearse: archive old XCom and run history to speed schema migration, then rehearse on a copy of production.

6. 6

   Validate in parallel: run critical DAGs side by side and compare outputs before switching.

7. 7

   Cut over with hypercare: a scheduled cutover with a tested rollback, then two weeks of heightened monitoring.

A managed Airflow service from a cloud provider keeps the platform running. It doesn't own your DAGs, dependencies, upgrade timing, alerting or costs, and that is where most incidents start. Our managed service covers that layer on whichever platform you run.

What's included in every tier

24/7 health monitoring of scheduler, triggerer, API server, workers, queue and metadata database · incident response and root-cause analysis · patching of Airflow core, providers and Python dependencies, including CVE remediation · capacity, pool and executor tuning · environment rightsizing · RBAC, SSO and secrets rotation · backups and tested disaster recovery · DAG deployment pipelines and release gates · service reviews covering SLA attainment, incidents, cost and roadmap.

Tier detail

Priority definitions

P1 Critical — production Airflow unavailable, or business-critical pipelines failing with no workaround. P2 High — degraded performance or a partial outage affecting important pipelines. P3 Medium — a non-critical issue with a workaround. P4 Low — questions, requests and planned changes. Response time is the time until an engineer is actively working the issue; resolution targets and service credits belong in the contract, not on the website.

Onboarding in 90 days

1. 1

   Days 1–30, discover and stabilize: access and runbooks, monitoring and alert integration, a baseline health assessment and quick wins.

2. 2

   Days 31–60, harden: alerts tuned to business deadlines, patching, a security review, and a backup and disaster-recovery test.

3. 3

   Days 61–90, optimize: performance and cost improvements, an upgrade roadmap and the first service review.

Security

Least-privilege access through paths you approve, with every action logged; engineers bound by NDA and background-verified.

• Platform-agnostic: no incentive to push a platform; we recommend what fits your workloads and team.
• Full-stack context: we also run Kafka, Spark, Cassandra, Redis, Kubernetes and observability stacks, so an incident that crosses systems gets solved, not passed along.
• AI-ready: we orchestrate LLM and agent workloads with the approvals and audit trails enterprises require.
• Engineers on call, not ticket routers: the people who answer are the people who build Airflow platforms.