Last checked and updated on 24 May 2026
Apache Airflow DAG Release Series: Scheduler Support Windows and EOL Phases
Each Apache Airflow major version follows a two-phase support model: an active Maintenance window that receives bug fixes and new minor releases, followed by a Limited Maintenance window restricted to security patches and critical bug fixes only. Once a version exits both phases, it reaches EOL and receives no further updates of any kind.
Airflow does not publish a fixed support duration per major release -- window lengths depend on when the next major version stabilizes and when the community votes to terminate the previous line. In practice, active major versions have remained supported for several years before entering limited maintenance. As shown in the release table above, version transitions follow the cadence of the project's major milestones.
Releases follow Semantic Versioning (SemVer): MAJOR.MINOR.PATCH. Breaking changes trigger a MAJOR bump, new features a MINOR bump, and bug-fix-only patches a PATCH bump. Providers versioning is independent of core Airflow versioning -- a provider can release a new MAJOR without Airflow doing the same.
| Phase | What You Receive | When It Applies |
|---|---|---|
| Maintenance (Active) | Bug fixes, security patches, new MINOR and PATCH releases | From initial MAJOR release until community sets Limited Maintenance date |
| Limited Maintenance | Security and critical bug fixes only -- no new features or non-critical patches | From Limited Maintenance date until EOL/Terminated date |
| EOL / Terminated | No fixes, no patches, no support of any kind | After EOL date -- version is abandoned by the community |
The community always recommends running the latest available MINOR release within your active MAJOR line. Upgrading to the latest MAJOR release before the EOL date is strongly advised. Official lifecycle data is tracked on the Apache Airflow GitHub repository.
Scheduler Integrity Risks: Running Outdated Airflow Workers and Executors
Running an unsupported Airflow version exposes your DAG pipelines to unpatched executor vulnerabilities, broken provider compatibility, and silent task failures that are hard to trace in production.
Unpatched Security Vulnerabilities in the Webserver and API
Airflow's web UI, REST API, and authentication layer have historically been targets for privilege escalation and remote code execution vulnerabilities. The Airflow security team backports CVE fixes to supported versions only. An unsupported version will accumulate unpatched CVEs with no resolution path short of upgrading the entire instance.
Provider and Executor Incompatibility
Airflow providers (GCP, AWS, dbt, Spark, etc.) are versioned independently and regularly drop support for older Airflow core versions. Once your core Airflow version falls outside the provider's support matrix, you lose access to newer provider releases -- which often contain critical fixes for cloud SDK API changes. The same applies to executors: CeleryExecutor and KubernetesExecutor depend on libraries like celery and the Kubernetes Python client, both of which are upper-bounded per release and may no longer be compatible with current infrastructure.
Python and Database Engine Drift
Each Airflow MAJOR version pins support to specific Python and database engine ranges (PostgreSQL, MySQL). As shown in the release table above, older series require older Python interpreters and database versions that have themselves gone EOL. Running a stack of compounded unsupported components -- old Airflow, old Python, old PostgreSQL -- dramatically widens the attack surface for the metadata database that stores all your DAG run state, XCom data, and task logs.
DAG Parsing and Scheduler Regressions
Scheduler bugs that cause missed runs, double-triggered tasks, or incorrect dependency resolution are treated as critical fixes -- but only in supported versions. An unsupported version running in production may exhibit known-broken scheduler behavior with no community-supported path to resolution.
DAG Orchestration After EOL: Termination Status and Pipeline Migration Paths
When an Airflow version reaches EOL/Terminated, the Apache community immediately stops all patch activity -- no security fixes, no bug fixes, no new provider compatibility updates, and no Docker image releases for that version line.
What Stops at EOL
The community stops merging pull requests targeting the EOL branch. PyPI constraint files -- which Airflow relies on for repeatable installations -- are no longer updated for that version. Docker images on Docker Hub will persist but receive no further updates. The Helm Chart for Kubernetes deployments also stops supporting that Airflow version.
Provider Ecosystem Abandonment
Provider distributions (e.g., apache-airflow-providers-google, apache-airflow-providers-amazon) quickly stop declaring compatibility with the EOL Airflow core version. Within months of EOL, most cloud providers will have dropped their minimum Airflow version requirement past your installed version, meaning you are locked out of bug fixes for cloud integrations regardless of your willingness to update providers independently.
Migration Direction
Migration to the current stable MAJOR version is the only supported path. In practice, the largest migration jump -- from the Airflow 2.x series to the 3.x series -- requires reviewing DAG code that uses deprecated operators and TaskFlow API patterns that were restructured. The official upgrade documentation covers migration steps by series. Most teams find it useful to stand up a parallel Airflow 3 environment and migrate DAGs incrementally, running both environments in parallel during the cutover window rather than doing a hard switch.
CLI and UI Methods for Inspecting Your Running Airflow Scheduler and Metadata Version
The fastest way to check your Apache Airflow version is via the CLI: airflow version prints the exact installed version of the core package to stdout.
Command-Line Inspection
airflow version
This returns the full SemVer string (e.g., 3.x.y or 2.x.y). Run this in the same Python environment or container where the scheduler and workers are running -- not just on the local machine where Airflow CLI is installed.
Python Package Query
If you are inside a Python environment but the Airflow CLI is not on PATH, query the installed package directly:
pip show apache-airflow | grep VersionOr from within Python:
import importlib.metadata
print(importlib.metadata.version("apache-airflow"))REST API and UI
The Airflow REST API exposes version info at /api/v1/version. A GET request to this endpoint returns a JSON body containing the Airflow version and Git version of the running instance -- useful when checking a remote deployment without shell access.
curl -u admin:password http://<airflow-host>/api/v1/versionThe Airflow web UI also displays the version in the footer of every page, making it visible to anyone with UI access without needing CLI or API access.
Docker and Kubernetes Deployments
For Helm-based Kubernetes deployments, check the image tag used in your values.yaml or inspect the running pod:
kubectl exec -n <namespace> <scheduler-pod> -- airflow versionFAQ -- Apache Airflow Support Lifecycle & EOL
How long is each Apache Airflow major version supported?
Airflow does not define a fixed support window by calendar duration. Each major version goes through an active Maintenance phase (full bug fix and minor releases) and then a Limited Maintenance phase (security and critical fixes only). The length of each phase depends on when the community sets transition dates, which are tied to the maturity of the next major version. As shown in the release table above, windows have historically spanned multiple years before EOL.
Does Apache Airflow have Long Term Support (LTS) releases?
Airflow does not use an explicit LTS designation. Instead, the current stable MAJOR version acts as the de-facto long-term track, receiving active maintenance until the community votes to move it to Limited Maintenance. There is typically only one actively maintained MAJOR version at a time, so production environments should target the latest stable MAJOR series to receive the longest remaining support window.
What is the difference between Maintenance and Limited Maintenance in Airflow?
During the Maintenance (active) phase, a version receives new MINOR releases with bug fixes, non-breaking improvements, and security patches. During Limited Maintenance, only security vulnerabilities and critical bug fixes are backported -- no new features and no non-critical patches. Once a version exits Limited Maintenance entirely, it is EOL/Terminated and receives nothing.
How do I know if my Apache Airflow version is still supported?
Check the official version lifecycle table at the Apache Airflow GitHub README. Match your installed MAJOR version (retrieved via airflow version) against the State column. If the state shows EOL or Terminated, no further support is available. If it shows Limited Maintenance, only security fixes are still being released for that version.
What should I do when my Apache Airflow version reaches end of life?
Plan a migration to the current stable MAJOR version before the EOL date, not after. After EOL, provider packages rapidly drop compatibility with the old core version, constraint files stop updating, and Docker images freeze. The recommended approach is to stand up a parallel environment on the new MAJOR version, migrate DAGs incrementally, validate operator and provider compatibility, then cut over. The official Airflow documentation covers upgrade paths between major series.