Which Airflow install method fits your team
Most teams reading this are installing Apache Airflow fresh or moving an existing estate off Airflow 2, which reached end of life on April 22, 2026 and gets no fixes from that date. The first decision is which official method matches the platform your team already runs. The Airflow installation docs describe the Helm chart as the fit for teams that manage applications on Kubernetes with Helm. The chart manages the database schema and automates startup, recovery and restarts of the components, so the operational work shifts toward values files, secrets and the Kubernetes platform beneath it. Confirm that your cluster falls within the Kubernetes versions the Airflow 3.3.2 prerequisites list, which is 1.30 to 1.35, before you commit.
The production Docker images suit teams that already have their own orchestration and want Airflow packaged as containers without adopting the chart. The docs are explicit that you remain responsible for setting up the metadata database and creating and managing its schema, while the images are maintained by the people who build Airflow. Choose PostgreSQL or MySQL here, since the prerequisites rule out SQLite in production and do not support MariaDB as the metadata database. The PyPI install suits users familiar with installing and configuring Python applications who are not working with containers. You are then expected to install and run every Airflow component yourself, including the scheduler, webserver and workers, under your own process management.
The Docker Compose guide is useful for learning and exploration, but its own documentation says the compose file does not provide the security guarantees required for a production system, so it should not be the basis for a production estate. Before you pick a method, check your team's container and Python skills, who will own upgrades and database backups, and whether the scheduler and executor you need, covered in the executor comparison, fit the method you choose. Ask any vendor or partner quoting the work to state which of these responsibilities sit with them and which stay with your staff.
Helm chart, production images and PyPI compared
This table compares the three official Airflow installation methods on documented suitability, database schema ownership, startup and restart handling, component installation, upgrade path and skills required. Read each row as what the Airflow docs state, and use the items marked to confirm as questions for your own platform team before you commit.
| Area | Official Helm chart on Kubernetes | Production Docker images | PyPI install on hosts you manage |
|---|---|---|---|
| Documented suitability | Teams that manage applications on Kubernetes with Helm | Teams that run containers in their own orchestration and build on the images | Users familiar with installing Python applications who are not familiar with containers |
| Database schema | The chart manages the database schema | You set up the database and create and manage the schema | You set up the database and manage the schema yourself (confirm the exact steps in the install docs) |
| Startup, recovery and restarts | The chart automates startup, recovery and restarts of components | Handled by your orchestration layer (confirm the expected configuration in the docs) | Handled by your own process managers or service units (confirm with the docs, not documented as automated) |
| Component installation | Chart deploys the Airflow components on the cluster | You deploy each component from the image into your orchestration | You are expected to install all Airflow components on your own |
| Upgrade path | Upgrade through the chart release (confirm chart version pairing with the Airflow version) | Move to new image tags and handle schema changes in your own rollout | Upgrade the Python packages and run the migration steps yourself (confirm the sequence in the docs) |
| Skills required | Kubernetes operations and Helm, plus Airflow configuration | Container build and orchestration skills, plus database administration | Python packaging, host administration, database administration and service management |
| Docker Compose quick start | Not a production option | Not a production option | Not a production option |
Which method suits your environment
The Airflow installation docs say the official Helm chart suits users who manage applications on Kubernetes with Helm. The chart manages the database schema and automates startup, recovery and restarts of the Airflow components, so a team with Helm practice takes on less of the routine lifecycle work than it would with raw images. You still own the cluster, the metadata database and the values you set for each environment.
- Database ownership: the chart handles schema management, but you still choose and operate the PostgreSQL or MySQL instance that backs it, including backups and capacity.
- Values as code: environment differences live in Helm values files, so review, version control and promotion through your existing pipeline apply directly.
- Secrets and identity: connections, fernet keys and login settings need a deliberate home. Kubernetes Secrets are stored unencrypted in etcd by default, so confirm encryption at rest on your cluster.
- Upgrades: you own the chart version and Airflow version pairing, and you test major upgrades before rolling them out.
- Kubernetes lifecycle: Kubernetes minor versions go out of support on a fixed schedule, so the cluster upgrade calendar becomes part of Airflow operations.
Before you commit, confirm that your cluster version falls within the Airflow 3.3.2 prerequisites and that your security team accepts the chart's default pod settings.
Teams on Nomad, OpenShift, Docker Swarm or a platform built on another scheduler will find that the Airflow docs point to the production Docker images rather than the Helm chart. The images are maintained by the people who build Airflow, but the docs make you responsible for the database, its schema and the wiring between Airflow components. Everything the chart would have automated becomes a platform task you design, test and document yourself.
- Database and schema: you set up the database and create and manage the schema during install and every upgrade.
- Component topology: scheduler, webserver or API server, workers and triggerer are yours to define, restart and scale in your orchestrator's terms.
- Recovery: health checks and restart policies must be written for your platform, since the chart's automated restart behavior does not carry over.
- Image supply chain: you decide how images are pulled, scanned, pinned and promoted into your registry.
- Multiple schedulers: Airflow supports more than one scheduler at once, using database row-level locks, but you must size and monitor them yourself.
Ask your platform team to map each chart responsibility to a concrete owner before choosing this path, and confirm which executors your orchestrator can support.
The Airflow docs say a PyPI install suits users familiar with installing and configuring Python applications who are not familiar with containers. It fits teams that already manage virtual environments, configuration management and service units on hosts. The docs state that you are expected to install all Airflow components on your own, so every process, dependency and host is part of your scope.
- Full component install: scheduler, API server, DAG processor, triggerer and workers are all set up by your team on each host.
- Dependency control: provider packages, Python versions and OS libraries must be pinned and kept consistent across hosts.
- Database setup: a production PostgreSQL or MySQL backend is required, since the production guide warns that the default SQLite backend is for testing only.
- Service management: process supervision, log rotation and restarts depend on tooling you already run, such as systemd or your configuration management.
- Host hardening: patching, access control and network segmentation of each host fall to your security and operations teams.
Confirm that your hosts meet the Python versions listed in the prerequisites and that someone on the team has run Airflow in this style before committing to it.
What you remain responsible for after installing Airflow
Every official installation method leaves some operational work with your team, and the Helm chart takes the least of it. The first item is the metadata database. Airflow 3.3.2 supports PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases. MariaDB is not supported as a metadata database, and SQLite should not be used in production. Under the production Docker images and the PyPI install, you set up that database, size it, back it up and manage its schema. Confirm your database version against the prerequisites page before you build, because a version outside the supported list is a support question you will have to answer yourself.
Schema management is where the methods differ most. With the production Docker images, the installation docs make you responsible for creating and managing the database schema, so every upgrade includes a schema step in your change process. The official Helm chart manages the schema and automates startup, recovery and restarts of the components, which removes that step from your runbook but not from your risk review. Whichever method you choose, decide who runs schema changes, when they run during a maintenance window, and how you roll back if a migration fails.
Scheduler and executor choices also stay with you under every method. Airflow supports more than one scheduler at once through database row-level locks, so you decide how many run and where. Executors are a separate decision: LocalExecutor, CeleryExecutor, KubernetesExecutor and others are available, and the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. Version upgrades complete the list. Airflow 2 reached end of life on April 22, 2026, so plan a regular upgrade cadence and track the Airflow supported versions page for each release line you run.
What the Kubernetes path depends on
The official Helm chart is only as stable as the Kubernetes cluster under it. The cards below cover the version match, the support window, the upgrade order, control plane availability and how credentials are stored, each of which stays your responsibility even when the chart automates startup and restarts.
Airflow and Kubernetes version match
Airflow 3.3.2 lists Kubernetes 1.30 to 1.35 as its supported range, so a cluster outside that band is outside the tested configuration. Check this before choosing a chart version, because a cluster that is newer than the range may still work but is not covered by the prerequisites. Ask your platform team which minor version each cluster runs today and whether a planned Kubernetes upgrade would move it out of the range.
Kubernetes support window
Kubernetes maintains only the three most recent minor releases, so a cluster on an older minor loses upstream patches on a fixed schedule. As of September 2026, 1.35 is maintained until February 28, 2027, which is the nearest deadline in the supported set. Plan cluster upgrades against these dates, and confirm with your Kubernetes distribution vendor when it ships patches relative to upstream.
Version skew during upgrades
The version skew policy requires the API server to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets. Kubelets may run up to three minor versions behind the API server, which gives you room to stagger node upgrades. Your upgrade runbook should sequence control plane and node pools in that order and test the Airflow chart against each intermediate step where the skew is tight.
Control plane and etcd availability
If you run your own clusters with kubeadm, the high availability guide describes a stacked topology or an external etcd cluster, with at least three control plane nodes behind a TCP load balancer on port 6443. Etcd should have an odd number of members, and the Kubernetes documentation recommends five in production. Confirm who owns etcd backups and restore drills, since the Airflow chart cannot recover a cluster whose control plane is lost.
Secrets stored unencrypted by default
Kubernetes stores Secrets unencrypted in etcd unless you configure encryption at rest, so Airflow connection strings, database passwords and Fernet-style keys are exposed to anyone who can read etcd backups. Restrict list and watch access with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver. Ask your security team whether encryption at rest is enabled on each cluster before the chart receives its credentials.
Questions teams ask before choosing an Airflow install method
Does the official Airflow Helm chart remove operating work?
Partly. The Airflow installation docs say the chart manages the database schema and automates startup, recovery and restarts of the components, which covers a real share of day-to-day toil on Kubernetes. It does not remove the work around it: you still provide and back up the metadata database, size and monitor the cluster, manage secrets and upgrades, and decide how DAGs reach the scheduler. Confirm with your platform team which of these the chart's values and your existing tooling handle in your environment before counting it as saved effort.
What does an implementation partner charge for an Airflow install, and what drives the quote?
DeployOpen does not publish a price list, and a quote follows from a written scope agreed before work starts. The main cost drivers are the number of environments, the install method and executor choice, the database and secrets integration, identity and network constraints, backup and upgrade procedures, and the documentation and handover you need. Most engagements are fixed-scope, so ask for scope, deliverables and timelines in writing, plus which items are one-time work and which are retainers for ongoing support or upgrades.
How long does a production Airflow install take?
No timeline can be given without knowing your environment, and this page does not state one. The effort depends on the install method, whether Kubernetes already exists, how many components and executors you run, and how far the database, identity and secrets integration must go. Ask any provider, including DeployOpen, to break the timeline into phases with named deliverables and the client inputs each phase needs, such as access, network rules and approvals.
What skills does our team need to run Airflow on a Helm chart?
You need people who can operate Kubernetes and Helm, and who understand Airflow's components. The Airflow docs say the Helm chart suits teams that already manage applications on Kubernetes with Helm. Kubernetes itself requires skills in cluster upgrades, the version skew rules, etcd backups and access control, since those tasks sit beneath Airflow. A PyPI install asks for Python application administration skills instead, and the docs say you are expected to install all Airflow components yourself.
Can we install Airflow ourselves without a partner?
Yes, if your team matches the skills the chosen method assumes. The official installation docs cover released sources, PyPI, production Docker images and the Helm chart, and they state that the community provides no specific documentation for managed services or third-party images or charts. Use the Docker Compose quick start only to learn the product, since its compose file does not provide the security guarantees required for production. A partner is most useful where you lack skills, need hardening or compliance evidence, or want a documented handover.
Is the Docker Compose quick start safe to use as a production install?
No. The Airflow Docker Compose guide says its compose file does not provide the security guarantees required for a production system and is useful for learning and exploration. It also asks for at least 4 GB of memory for Docker, ideally 8 GB. For production, move to the production Docker images, the Helm chart or a PyPI install with a PostgreSQL or MySQL metadata database, since the production deployment guide warns that the default SQLite backend can lead to data loss.
Which Airflow version and database should a new install target?
Target Airflow 3 with a supported database. Airflow 2 reached end of life on April 22, 2026, and gets no fixes after that date, while Airflow 3.3.2 is the current release. The 3.3.2 prerequisites list PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases, and state that MariaDB is not supported as a metadata database. Ask your provider to confirm the version and database pairing against your own Kubernetes or host platform before you commit to a plan.
How Airflow 2 end of life changes the install decision
Airflow 2 reached end of life on April 22, 2026, so any cluster still running it gets no fixes, including security fixes. Airflow 3 was first released on April 22, 2025, and the current patch release is 3.3.2. For most teams the install decision is now really an upgrade decision, because the method you pick determines how much of the Airflow 3 migration you carry yourself. The three methods differ less in the Airflow code they run than in who owns the database schema, the component startup and the restarts after a failed upgrade.
The Helm chart manages the database schema and automates startup, recovery and restarts of the components, so a chart-based estate has the most automation to lean on during the move. A production Docker image deployment leaves database setup and schema management with your team, and a PyPI install leaves you responsible for every component. Before you upgrade, confirm which executors you run. The hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0, so any DAG or deployment that depends on them needs a different executor configuration before the cutover. Check the Airflow upgrade guide for Airflow 3 against your DAGs and plugins.
Also confirm your metadata database and Python versions against the Airflow 3.3.2 prerequisites before choosing a target. Plan a rollback path for each method: with the chart, check how it handles a failed migration; with images or PyPI, keep a tested database backup and pinned previous image or package versions. The Docker Compose quick start cannot serve as a staging rehearsal for production, since its compose file does not provide the security guarantees required for a production system. Use a staging environment that matches your production install method.
How to pick and validate a method in four steps
This sequence turns the three official Airflow installation methods into a documented decision, so the team knows who owns the database, schema changes and restarts before anything reaches production.
Confirm Kubernetes and Helm skills in the platform team
Start by listing who on the platform team already operates Kubernetes workloads and Helm releases, and who would be paged when a pod restarts at night. The Airflow installation docs say the official Helm chart suits users who manage applications on Kubernetes with Helm, so if that skill is missing, the chart is not a shortcut. If the team is strong on Python packaging but not on containers, the docs describe PyPI as the fit, with you expected to install all Airflow components yourselves. Done means a named owner for the cluster and the Airflow release, written down with the method chosen.
Confirm the metadata database and its support range
Choose PostgreSQL or MySQL as the metadata database, because the production deployment guide warns that the default SQLite backend is for testing only and can lead to data loss. Check the Airflow 3.3.2 prerequisites for supported versions: PostgreSQL 14 to 18, MySQL 8.0, 8.4 and Innovation releases, and MariaDB is not supported. Confirm that your managed or self-run database falls inside that range before you commit. Done means the database engine, version and host are recorded, and you know whether your method or your team owns its backups and schema.
Assign ownership of schema changes and restarts
Decide who runs database migrations on each upgrade and who handles component restarts and recovery. With the production Docker images, the installation docs say you are responsible for setting up the database and creating and managing the database schema, while the image comes from the people who build Airflow. With the official Helm chart, the docs say the chart manages the schema and automates startup, recovery and restarts of components. With PyPI, you own all of it. Done means a responsibility matrix lists each task, its owner and the runbook location for upgrades and rollback.
Check the Kubernetes version against the Airflow support window
If the method runs on Kubernetes, confirm that your cluster version falls in the Airflow 3.3.2 prerequisite range of Kubernetes 1.30 to 1.35, and check the Kubernetes release page for each cluster version's end-of-life date. Plan upgrades with the version skew policy in mind, because the kube-apiserver must be upgraded one minor version at a time before the other control plane components and kubelets. Done means a dated cluster upgrade path is documented alongside the Airflow upgrade path, and both teams agree on which comes first.
Run a non-production pilot before committing
Install the chosen method in a non-production environment that mirrors your database, executor and secrets setup, not the Docker Compose quick start. The Compose guide says its file does not provide the security guarantees required for production and is for learning and exploration. During the pilot, run a test DAG, trigger a restart of a component, and perform one schema migration against a copy of the database. Done means the pilot results, including any failed step and how it was fixed, are recorded and reviewed by the owners named in the earlier steps.
Confirm security controls for secrets and access
Before production, confirm how connection strings and Airflow secrets reach the pods or hosts. Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. Also confirm how users authenticate to Airflow through its auth manager. Done means each secret path and access grant is documented and tested, and an independent reviewer has signed off on the configuration.
Record the decision and request a scoped quote
Write a short decision record that states the chosen method, the reasons drawn from the steps above, the owners and the pilot results. If you want DeployOpen or another partner to implement or harden the chosen method, use that record as the basis for a written scope, since DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list. Done means the decision record is approved and the scope document lists the responsibilities that will move to the partner, if any.
How DeployOpen plans and delivers Airflow installs
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache Airflow. For the Helm chart, Docker image and PyPI paths, the work starts with a written scope that fits the install method to your Kubernetes, host and database setup, not the other way around.
How we scope
- The written scope names the install method chosen, the Airflow version and the Kubernetes or host platform it runs on.
- Scope lists the metadata database, executor choice, secrets handling and the networks and cloud accounts involved.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build work starts.
How we build
- We deploy Airflow in your own cloud account, data center or air-gapped network using the method your scope specifies.
- Builds cover the database setup and schema handling, scheduler redundancy, executor configuration and component startup.
- Security testing and hardening steps are applied to the install and results are recorded against the agreed scope.
How we hand over
- Handover includes documentation of the install, configuration keys, upgrade path and operating responsibilities.
- Your team receives written records of what DeployOpen owns, what your team owns and what remains open items.
- Backup and restore procedures for the metadata database and related components are documented and handed over.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Upgrade planning covers Airflow end-of-life dates and the Kubernetes or Python versions each release requires.
- Before relying on any version, support window or feature in your environment, confirm it with the Airflow project and your own team.
