Because providers are released separately from Airflow core, a provider upgrade can pull in or demand versions that conflict with what you already run. Pip check reports broken requirements in the installed set. Exit code 0 means no conflicts were found. It is a cheap gate to run after every dependency change.
Why provider upgrades need a gate
The Airflow providers documentation says community providers are "released and versioned separately from the Airflow releases" and follow Semver. That separation is useful: you can patch a provider without upgrading core, and roll one back if it misbehaves.
The installation docs add a caution. Separate provider upgrades or downgrades are "not guaranteed to work" with every Airflow version or every other provider. They also advise installing extra packages and providers in a separate command from the constrained Airflow install, and pinning apache-airflow to your current version in that command so pip does not change it.
That leaves a window where a perfectly reasonable upgrade leaves the environment in a state nobody tested.
What pip check does
Pip check looks at the installed packages and reports any whose declared requirements are not met. The Airflow docs use it to confirm that an environment has no conflicts and state that exit code 0 means none were found.
It does not tell you whether a package is safe, whether it has advisories, or whether DAGs still work. It only answers one question: do the installed packages agree with each other?
Where to put it
Add it at the end of the step that builds the environment.
pip install "apache-airflow==YOUR_VERSION" apache-airflow-providers-example
pip check
Make the build fail on a non-zero exit. Do this in the image build, not on the running workers. A conflict found at build time is a failed pipeline. A conflict found at run time is a failed schedule.
A short upgrade routine
- Read the provider's release notes. Cross-provider requirements and breaking changes are documented there.
- Install the provider in a copy of your build, with your Airflow version pinned.
- Run pip check.
- Scan the resulting package set for known advisories.
- Run a representative DAG in a test environment.
- Promote the same image, not a rebuild.
What else to compare
After a provider upgrade, compare the full package list before and after. Provider upgrades can change many transitive packages, and a diff of the inventory shows you the real size of the change, which a version bump in a pull request hides.
Safeguard's SBOM and dependency scanning and its gates can run in that pipeline step, comparing inventories and checking for known advisories before the image is promoted. The free scan at https://gold.safeguard.sh/scan is a quick way to try it on a repository.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a failing check stops the change before it merges.
Quick check
Does pip check find vulnerable packages?
No. It only reports unmet requirements between installed packages. Use a scanner for advisories.
Can I upgrade a provider without upgrading Airflow?
Yes, that is the point of separate packaging, but the docs say it is not guaranteed to work with every core version.
Sources
Last reviewed: 19 October 2026.
