Both approaches can be maintained safely. Extending suits adding packages that need no compiling and is quicker to rebuild, which helps patching. Customizing suits compiled dependencies and tight image size. Either way, pin the Airflow version, use constraints, and rebuild on a schedule.
The two options
The Airflow Docker stack documentation says extending uses a FROM build and is easiest when you only add dependencies that do not require compiling. Customizing suits compiled dependencies, size optimized images, forked sources and air gapped builds. The page cites roughly 1.1 GB for an extended image against about 874 MB for a customized equivalent. You can combine them: an admin team publishes a customized base, and others extend it.
What matters for security
| Factor | Extend | Customize |
|---|---|---|
| Rebuild speed | Faster | Slower, more setup |
| Image size and attack surface | Larger | Smaller |
| Compiled or system dependencies | Limited | Supported |
| Expertise needed | Basic image skills | More |
| Air gapped builds | Harder | Supported |
Smaller images carry fewer packages to patch. Faster rebuilds mean patches land sooner. Pick based on which of those your team will actually sustain.
Habits from the docs that help either way
- Install pip packages as the airflow user. The docs say pip as root fails.
- Install the same apache-airflow version as the base image in the same command. The docs say this is good practice, and conflicts then produce an error instead of a silent core change.
- Pin your requirements with exact versions.
- Use the constraints file. From Airflow 2.9.0 the file used to build the image is at a home directory path inside it, and you can pass it to pip as a constraint. See the constraints file explainer.
- Switch to root only for apt installs, then back to the airflow user.
- Rebuild regularly. The docs say to rebuild when packages or the Airflow version change and to keep build scripts in version control, and recommend regular rebuilds to pick up security fixes.
Beyond the Dockerfile
Pin the base image by digest rather than a tag when your policy allows, and sign what you build. Our note on why to sign the image digest, not the tag explains why. Scan the final image, not only the requirements file, because system packages come from the base.
A simple routine
Rebuild monthly, scan the result, compare the package list to last month, and roll out through staging. Rebuild immediately for a critical advisory in a provider or library you use.
Try it yourself
Click through the container scan and look at how findings are grouped by layer, then think about which layer your own Airflow image would put them in.
Click through it at your own pace, or open it full screen.
Quick check
Why install the same Airflow version in my Dockerfile?
So pip reports a conflict instead of silently changing core. The docs recommend it.
Is a smaller image automatically safer?
It has fewer packages to patch, but it is only safer if you rebuild and scan it.
Safeguard's container image scanning can check the built image for vulnerable components. Try the demo below, and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
