Apache Airflow Support Options After Airflow 2 End of Life

Apache Airflow has no vendor. Airflow support comes from the Apache Airflow community for maintained versions, from the providers of managed Airflow services, and from independent providers for self-managed Airflow deployments, including Airflow 2, which is now end of life.

What the Airflow community supports

Apache Airflow is an Apache Software Foundation project, a platform created by the community to programmatically author, schedule and monitor workflows. The project's supported versions page defines the version lifecycle plainly. Limited support versions get security and critical bug fixes only. End-of-life versions will not get any fixes or support.

At the time of writing, Airflow 3, first released on 22 April 2025, is the maintained version. Airflow 2 entered limited maintenance on 22 October 2025 and reached end of life on 22 April 2026. Many production Airflow environments are still on 2.x. They still run. They no longer receive security fixes from the project.

The same page covers dependencies. Airflow drops support for a Python or Kubernetes version once it reaches its own end of life, in the first new minor or major release afterwards, so the version of Airflow you can run is tied to the Python and Kubernetes versions underneath it. Community support itself means GitHub issues, the mailing lists and Slack, answered by committers and users in their own time.

Managed Airflow

Astronomer's Astro, Amazon MWAA and Google Cloud Composer run Airflow for you and support their own service: the scheduler, the workers, the metadata database, upgrades. They do not support your DAGs. A pipeline that fails because of a dependency conflict, an XCom that is too large, a provider package that changed behaviour, or a task that never leaves the queued state is your problem on any of them, and each service supports only a window of Airflow versions.

Where independent Airflow support fits

• Self-managed Airflow 2.x past end of life, while the migration to Airflow 3 is planned. The move is a real project: deprecated features are removed, the API and the task SDK change, and DAG code needs review.
• Scheduler and executor problems: zombie tasks, a scheduler that stops scheduling, slow DAG parse time from top-level code, task instances stuck in queued, Celery or Kubernetes executor misconfiguration.
• The metadata database, which is usually PostgreSQL and is usually the real bottleneck.
• Deploying Airflow on Kubernetes with the official Helm chart, Docker images, DAG deployment and versioning, secrets and connections.
• Best practices for the DAGs themselves, because most dag failures are pipeline design, not platform faults: idempotency, retries, sensible dependencies and integration with the systems at each end.

AceMQ provides 24/7 Airflow support with a 15-minute emergency SLA and named senior engineers, for self-managed and managed deployments. Examples: a zombie task and scheduler remediation and DAG parse time support.

The Airflow incidents that actually page people

• Tasks stuck in queued or scheduled. The scheduler is alive but nothing runs. Pools are exhausted, the executor has lost track of its workers, parallelism limits are hit, or the Kubernetes executor cannot create pods because of a quota or an image pull failure.
• Zombie and orphaned tasks. A worker dies mid-task, its heartbeat stops, and the scheduler marks the task failed or leaves it running forever. Retries then double-load a table because the task was not idempotent.
• Slow DAG parsing. Top-level code in DAG files, such as a database query or an API call at import time, runs on every parse loop. The scheduler spends its time parsing instead of scheduling, and new DAG runs start late.
• The metadata database. Years of task instance, log and XCom rows slow every scheduler query. Large XCom values stored in the database make it worse. Regular cleanup with the db clean command and an XCom backend on object storage fix what more hardware will not.
• Dependency conflicts. Providers, the constraints file and a team's own Python packages disagree, and an innocent pip install breaks the scheduler. Isolating task dependencies with virtual environments, the Kubernetes pod operator or separate images is the durable answer.

Migrating from Airflow 2 to Airflow 3

Airflow 2 is end of life, and Airflow 3 is an architectural release, not a routine upgrade. Tasks no longer access the metadata database directly and instead talk to an API server through the task SDK, which breaks custom operators and DAGs that queried the database. The REST API moved to a new version, SubDAGs and other long-deprecated features were removed, the scheduling vocabulary changed from datasets to assets, and some configuration and import paths moved. The project recommends upgrading to the last 2.x release first and clearing every deprecation warning there. It also ships a Ruff-based linter that flags incompatible DAG code, which turns the migration into a measurable backlog. Budget for testing every DAG, not only the platform.

Choosing

On a managed service and a current version, the provider covers the platform and you need help only with DAGs. If you run Airflow yourself, the community gives you fixes for Airflow 3 and nothing for Airflow 2, and gives nobody a response time. If your data pipelines feed revenue, reporting deadlines or regulated processes, put a contract behind the orchestration layer.