An Airflow constraints file is a pinned list of dependency versions that the project tested together at release. You pass it to pip during install so you get the same working set each time. If you run Airflow in production, yes, you want one, or your own frozen copy of it.
Definition
Airflow is both a library and an application, so its dependencies are loose in the project metadata. The installation docs say constraint files keep a tested set of dependencies at the moment of release, so you can reproduce a known good installation.
Each release has a tag, and each Python version has its own file, following this URL shape:
https://raw.githubusercontent.com/apache/airflow/constraints-AIRFLOW_VERSION/constraints-PYTHON_VERSION.txt
Replace the two placeholders with your Airflow release and Python version. A separate no providers variant exists for a core only install.
How to use it
pip install "apache-airflow[celery]==YOUR_VERSION" --constraint "CONSTRAINTS_URL"
The docs say uv follows the same approach and should work similarly.
What it pins and what it does not
- It pins Airflow's dependencies and the providers released alongside that Airflow version.
- It applies only to the install command where you use it. To upgrade a provider later, run a separate install without the constraint, and pin apache-airflow to your current version.
- It is not updated after release except in rare cases. For newer dependency versions, upgrade Airflow or maintain your own constraints.
- It does not provide OS packages. The docs note that some providers need build tools or database client libraries.
Why it matters for security
Reproducibility is a security property. If two builds a week apart can resolve different transitive libraries, you cannot say what is running. A constraint file also means a security fix in a dependency does not arrive until you decide to take it, which is the trade off: stable but stale unless you refresh on a schedule.
Keeping your own
After you install and adjust packages, the docs suggest freezing the environment into a file such as my-constraints.txt and reusing it as the constraint source, locally or hosted where you control it. Pair it with hash checking if you want stronger guarantees, see pinning pip requirements with hashes.
A refresh routine
- Pick a cadence, such as monthly plus on critical advisories.
- Build a candidate image with new constraints in CI.
- Run pip check and your Dag tests.
- Compare the package list against the previous build.
- Ship, and keep the previous image.
Quick check
Does the constraints file stop me from upgrading a provider?
Not if you run a separate install without it and pin Airflow, as the docs describe.
Will the official constraints get security updates?
The docs say they are not updated after release except in rare cases. Upgrade Airflow or keep your own file.
Safeguard dependency scanning reads pinned files and flags components with known advisories, which suits a refresh routine. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
