Why an Apache Airflow Helm chart install is harder than the quick start suggests
A platform team asked to run Apache Airflow on Kubernetes under its own controls will find that the community Helm chart and the official Docker image are the supported path, but the chart is not the hard part. The hard parts are decisions that must be made before the first install: an external metadata database, how DAG code reaches the scheduler and workers, where task logs go, and which Airflow major version and Kubernetes version the platform will carry. Installing the chart with its defaults produces a running cluster that is not yet a deployment you can operate, audit or upgrade. The first version decision is the Airflow line. Airflow 3 splits what Airflow 2 ran in fewer processes into separate components: the scheduler, the DAG processor, the API server (started with airflow api-server, which replaces the webserver) and the triggerer. The DAG processor must run as its own component in Airflow 3, so the chart values need a deployment for each one. Airflow 2 reached end of life on April 22, 2026, after which it gets no fixes, so a new rollout should target Airflow 3 unless there is a documented reason to stay on a supported 2.x line.
The metadata database is the first setting to change. The default SQLite backend is for testing only and can lose data in production, so the chart must point at an external PostgreSQL or MySQL instance. Confirm the exact supported versions for your Airflow release against the prerequisites page, since the current Airflow 3 list covers PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases, and MariaDB is not supported. Ask who owns the database, how its backups are restored, and whether the connection secret is stored in your secrets system rather than in a values file committed to git. DAG delivery is the next decision. Git-sync and baking DAGs into the image each change how quickly code moves, how rollbacks work and who can release a pipeline. Pick one method per environment, write down which repository and branch are authoritative, and decide how a broken DAG is rolled back. Logging is the third decision: task logs written only to pod-local storage disappear when pods are replaced, so plan a remote log destination that your retention and access rules allow. Treat the chart as a starting point, not a finished configuration. Every environment needs its own values for resources, replica counts, ingress, probes, service accounts and secrets references, and each of those values should be reviewed against your Kubernetes version. Confirm the supported Kubernetes range for your target Airflow release (the current Airflow 3 prerequisites list 1.30 to 1.35) and check the chart release notes before each upgrade, because chart and Airflow versions move on separate schedules.
Which Airflow components the chart has to deploy and wire together
The community chart deploys several Airflow processes that share one metadata database and one DAG source, so a single wrong value can stall the whole platform. The cards below cover each component, what it does, and what breaks when it is misconfigured. Triggerer, log storage and executor details are wired in the same values file and are covered in the text.
Scheduler
The scheduler reads parsed DAGs from the metadata database, decides which task instances are ready, and queues them for execution. Airflow supports running more than one scheduler at the same time, coordinated through database row-level locks, so you can set replica count as a resilience decision. Check that every replica points at the same database and that the database connection pool is sized for all of them. If the scheduler is misconfigured, tasks sit in queued state or DAG runs never start, and the UI may still look healthy.
DAG processor
In Airflow 3 the DAG processor is a separate component. It parses DAG files, serializes them, and writes the results to the metadata database so the scheduler and API server can read them. Because the upgrade guide requires it to run separately, a values file carried over from Airflow 2 may not deploy it at all. Confirm the chart creates a DAG processor deployment, that it mounts the same DAG source as the scheduler, and that parse errors surface in logs. If it is missing or pointed at a stale path, new DAGs never appear in the UI.
API server
The API server replaces the Airflow 2 webserver and is started with the airflow api-server command. It serves the web UI, the REST API that the Task SDK and external systems call, and it is the endpoint your users and ingress controller reach. Check the ingress path, the base URL setting, and the secret used to sign sessions and tokens, which must match across replicas. If the API server is misconfigured, users see login loops or broken links, and tasks that depend on the API fail even when the scheduler runs normally.
Metadata database
The metadata database stores DAG runs, task state, connections, variables and the locks that coordinate schedulers. Airflow's prerequisites list PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases for Airflow 3.3.2, and state that MariaDB is not supported and SQLite should not be used in production. Plan an external database instead of the chart's bundled test instance, size its connections for every scheduler and API server replica, and confirm backup and failover ownership. A wrong engine or version usually fails during migration, and an unbacked database makes history loss permanent.
DAG source delivery
The scheduler, DAG processor and workers must all see the same DAG files, and the chart offers git-sync or DAG files baked into the container image. Git-sync keeps DAG releases separate from image builds but adds a repository credential and a sync interval to manage. Baked images are simpler to pin and promote, though every DAG change then needs an image rebuild. The production guide recommends container images for Kubernetes deployments. Check which method you chose, that credentials are stored as Kubernetes secrets, and that all components load the same revision. Mismatched revisions cause tasks to run code the scheduler never parsed.
Executor pods and workers
The executor decides where task instances run, whether as Kubernetes pods created per task, as Celery workers, or in another execution model. The chart creates the resources that executor needs, such as worker deployments, service accounts and pod templates, so the executor value and its matching resources must agree. Choosing between executors is a separate decision covered in the executor selection topic, so settle it before tuning this part. Check the service account permissions, the namespace where pods launch, and the image each worker pulls. A mismatch leaves tasks queued forever or fails them at launch.
Which DAG delivery, executor and database choices fit a Helm deployment
This table compares the three choices that shape the Airflow Helm values file: how DAGs reach the scheduler, which executor runs tasks, and where the metadata database lives. Read each row for when the option fits, what it asks of your operations team, and which settings to confirm in the chart's configuration reference before you commit. The main takeaway is that DAG delivery and database backups are the choices most often underestimated after go-live.
| Decision | When it fits | Operational cost and what to confirm |
|---|---|---|
| git-sync for DAG delivery | DAG authors ship changes often and you want DAG releases decoupled from image builds | Needs a Git credential stored as a Kubernetes secret, a sync interval, and a rollback path through Git history. Confirm the git-sync settings and how the chart mounts the SSH key or token in the chart reference. |
| DAGs baked into the image | Releases are gated, reproducible and tied to a tested image tag | Every DAG change becomes an image build and a Helm upgrade, which slows hotfixes. Rollback means redeploying the previous image tag. Confirm the chart's image and dags persistence settings before choosing this path. |
| KubernetesExecutor | Tasks have uneven resource needs or you want one pod per task with no long-lived workers | Pod startup adds latency per task, and cluster capacity and quotas become the scaling limit. Confirm the executor value, pod template overrides and the worker namespace permissions the chart creates. |
| CeleryExecutor | You need warm workers, a broker you already operate, or steady high task throughput | You operate a message broker, scale worker deployments yourself, and manage worker secrets across replicas. Confirm the broker and result backend settings and whether the chart deploys Redis or expects an external broker. |
| External PostgreSQL | You already run a managed or HA PostgreSQL service in the same network as the cluster | Backups, failover, minor version patching and connection limits stay with your database team. Confirm the supported PostgreSQL versions (14 to 18 for Airflow 3.3.2) and how the chart reads the connection secret. |
| External MySQL | Your standards require MySQL and you can run an instance that meets the Airflow prerequisites | Supported versions are 8.0, 8.4 and Innovation releases, and MariaDB is not supported for metadata. Confirm the charset and connection string options in the chart reference before provisioning. |
| Bundled database in the chart | Proof-of-concept or test clusters only | Persistence, backups and upgrades of the bundled instance are your responsibility, and data loss is a real risk in production. Confirm whether it is disabled by default and plan a migration to an external database before go-live. |
| Hybrid CeleryKubernetesExecutor or LocalKubernetesExecutor | Not applicable to new Airflow 3 deployments | These hybrid executors are no longer supported as of Airflow 3.0.0. Use Celery or Kubernetes executors, or run multiple executors in one deployment, and confirm the chart values for your target release. |
How to install Apache Airflow with the Helm chart, step by step
This sequence takes a self-hosted Apache Airflow 3 deployment from version confirmation to a verified install in a non-production namespace, with each step closed by a check you can record. It follows the order the chart depends on: the database and image exist before the values are rendered, and the secrets exist before the release is installed.
Confirm the Airflow 3 release and Kubernetes range
The platform owner records the target release, Airflow 3.3.2, and checks the Kubernetes versions that release supports, 1.30 to 1.35, along with the supported Python range in the prerequisites. If you are moving from Airflow 2, the upgrade guide requires being on Airflow 2.7 or later first, so confirm your starting point now. This step closes with a written version matrix and the output of kubectl version against your target cluster, showing a server version inside the supported range.
Provision the external metadata database
The database administrator creates a dedicated PostgreSQL instance on a supported version from 14 to 18, or a MySQL 8.0 or 8.4 instance, hosted outside the cluster. MariaDB is not supported as a metadata database, and SQLite should not be used in production, so neither is an option here. Create a database user limited to the Airflow schema, then test the connection from a temporary pod in the target namespace. The step closes when a psql or mysql client inside the cluster connects with that user and returns the server version.
Build or select the Airflow image
The platform engineer starts from the official Airflow Docker image, which the community Helm chart uses and the production guide recommends for Kubernetes. Add only the providers and Python packages your DAGs need, install them against the Airflow constraints for the pinned version, and push the result to your private registry under a fixed tag. The step closes when airflow version run inside a container from that tag reports 3.3.2 and each added provider imports without error.
Set values for executor, DAG delivery and logs
The engineer writes a values file that sets the executor, the DAG delivery method, the log destination and resource requests. Choose an executor the release supports, noting that CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. For DAG delivery, select git-sync from a reviewed repository or DAGs baked into the image, and configure remote task logging. Size the scheduler and API server requests with the recommended minimum of 4 GB of RAM in mind. The step closes when helm template renders the chart and the output shows your image tag, executor and secret references.
Create Kubernetes secrets for connections and keys
The platform engineer creates Kubernetes secrets for the metadata database connection, the Fernet key used to encrypt stored connections, the git credential if DAGs come from a private repository, and any provider credentials. Keep these values out of the values file and shell history, and reference the secrets by name in the chart. If your organization already runs an external secrets tool, sync from it instead, and limit read access to the Airflow service account. The step closes when kubectl get secret lists each name with the expected keys.
Install the release into a non-production namespace
The engineer runs helm install with the reviewed values file into a dedicated non-production namespace, using the create-namespace option if the namespace does not exist and a pinned chart version. The chart starts a database migration job before the core components, so watch that job first. If it fails, stop and fix the database connection or permissions before retrying. The step closes when helm status reports the release as deployed and the migration job log shows the schema migration completing without error.
Verify scheduler, DAG processor, API server and triggerer
The engineer confirms that the scheduler, DAG processor, API server and triggerer are each running and Ready. Airflow 3 replaces the webserver with an API server and runs the DAG processor as its own component, so check all four separately. Read the DAG processor logs for a successful parse of a sample DAG, then run airflow dags list inside the scheduler pod to confirm the DAG is registered. The step closes when kubectl get pods shows all four components Ready and the sample DAG appears with no import errors.
Why the metadata database must be external before the first install
The metadata database has to live outside the Airflow pods before the first install. Airflow stores DAG runs, task instances, connections, variables and scheduler state there, so the database is the system of record for the whole deployment. The default SQLite backend exists for testing only, and the Airflow production deployment guide warns that running it in production can lead to data loss. A chart values file that leaves the database unset will start, which is why the decision needs to be made and recorded before anyone installs the chart, not after the first pipelines are running.
PostgreSQL or MySQL is the recommended choice. MariaDB is not supported as a metadata database, so an existing MariaDB service should not be reused without confirming support in the current prerequisites. The supported ranges change with the Airflow release, so check the Airflow 3.3.2 prerequisites for the exact PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation release lines before choosing a version. Decide up front which major version the database team will operate, how long that version will receive vendor support, and who approves a version change. Those answers constrain the Airflow release you can pin in the chart.
Several items need a decision before the first install, not during it. Connection pooling determines how many connections the scheduler, API server, DAG processor, triggerer and workers open against the database, so confirm the pooler design and connection limits with the database team. Backups and point-in-time recovery define how much metadata you can lose and how you restore it, and they should be tested on a copy of the instance. Network access must allow the scheduler, API server and DAG processor pods to reach the database through the cluster network policy, with no broad exposure beyond those workloads. Credentials should be delivered through a Kubernetes secret or an external secrets integration that the database team approves, rather than typed into values files.
Airflow supports running more than one scheduler against the same database at the same time, using database row-level locks. That makes the database the foundation of scheduler resilience, not only a storage location. A single shared database that is backed up, monitored and failed over properly is a precondition for a multi-scheduler design later. Ask the database team whether they can provide a highly available endpoint and what failover behavior applications must tolerate, because Airflow will hold connections through a failover event.
Confirm with the database team the engine and version, the instance sizing, the pooler and connection limits, backup schedule and retention, point-in-time recovery window, failover model, network paths, and the account and privileges Airflow will use for migrations. Moving the metadata database after go-live is possible but involves a planned maintenance window, a consistent export or replication step, a repointed connection secret, a database migration run against the new target, and verification that DAG runs and connections survived. Plan that cost and downtime now, because it is far simpler to choose the right database before the first install.
Securing the Helm release: secrets, auth and cluster access
Securing an Airflow Helm release means controlling where credentials live, which identities each component uses, and which pods can reach the metadata database. The controls below are Kubernetes-level decisions that apply before any identity integration, which is a separate choice in Airflow 3.
Keep credentials out of values files
Database passwords, connection secrets and the Fernet key should not be written into a values file committed to source control. Reference existing Kubernetes secrets from the chart instead, and confirm in the chart's values reference which keys it expects for the metadata database connection, the Fernet key and the webserver or API secret. Check that rendered manifests and Helm release history do not expose the values in plain text.
Choose a secrets source
Decide whether credentials come from native Kubernetes secrets or from an external secrets manager synchronized into the cluster. The choice affects rotation, audit trails and who can read secret objects in each namespace. Ask your platform team which store is the system of record, how rotation reaches running pods, and whether a restart is needed after a rotated value is picked up.
Scope namespaces and service accounts
Run the release in a dedicated namespace and give each component, including the scheduler, API server, DAG processor, triggerer and workers, a service account with only the permissions it needs. Pods that run user task code should not share an identity with the components that hold the Fernet key. Confirm the service account names and any role bindings the chart creates, and whether you need to supply your own.
Restrict traffic with network policies
Network policies should allow traffic from scheduler, API server, DAG processor, triggerer and worker pods to the metadata database and only the paths each component needs. Deny other ingress to the database by default. Confirm that your cluster's network plugin enforces network policies, and list the ports and destinations each component uses before writing rules, because a blocked connection often shows up first as a task or scheduler failure.
Pin the image version
Set the Airflow image tag explicitly rather than relying on a floating tag, so every component runs the same reviewed build and upgrades happen through a change you control. Airflow 3.3.2 is the current patch release in the supplied version data, but confirm the release you deploy against the version life cycle table before go-live. Record the digest in your change process and re-test when you move to a new patch.
Plan identity separately
Airflow 3 uses the Simple auth manager by default, and only one auth manager can be active at a time, set by the auth_manager option. Changing to another manager is a separate decision with its own role model and provider package, so do not treat the Helm release as the place where SSO is solved. Confirm which auth manager your release uses and document who can reach the API server until the identity design is approved.
What drives Helm deployment effort and how to keep each part down
This table lists the nine drivers that most change effort on an Apache Airflow Helm chart deployment, who usually does each part, what raises it and how to keep it down. Read each row against your own environment count and delivery model, since these drivers multiply each other. The main takeaway is that a standard values set, pre-approved database provisioning and one DAG delivery model usually reduce the work more than any single tool choice.
| Driver | Who typically does the work | What raises effort | How to keep it down |
|---|---|---|---|
| Number of environments | Platform team, with data engineering for values review | Each environment adds its own values files, secrets, database, ingress and upgrade cycle | Keep one base values file and limit per-environment overrides to a short, reviewed list |
| DAG count and delivery model | Data engineering, with platform team for sync setup | Several teams pushing DAGs by different methods, or a separate image build per DAG, multiplies review and rollback work | Choose one model, git-sync or a baked image, and enforce it through one repository and pipeline |
| Executor choice and worker scaling | Platform team | Kubernetes or Celery workers add pods, queues, autoscaling and capacity testing, and each executor needs its own tuning | Start with one executor, set resource requests from observed task profiles, and test scaling in a non-production cluster |
| External database readiness and access approvals | Database team, with platform team for connection secrets | New instances, network rules and approvals take time, and MariaDB or SQLite cannot serve as the metadata database | Request a pre-approved PostgreSQL or MySQL pattern in advance, using a version from the prerequisites list |
| Logging destination | Platform team, with security for retention rules | A new central logging system needs endpoints, index or retention decisions and access rules | Choose the existing logging stack early and reuse its agent and retention standards |
| Integrations and connections to internal systems | Data engineering, with security and system owners | Each source, warehouse or API needs network paths, credentials, connection definitions and tests | Inventory connections before the build, load credentials through the secrets backend and test each one in staging |
| Security review and secrets tooling | Security team, with platform team | Custom secrets stores, unapproved image sources and Fernet key handling extend review cycles | Reuse approved secrets tooling and agree on image sources and key rotation before the first deployment |
| Air-gapped image and chart mirroring | Platform team, with security for transfer approvals | Every image, chart version and dependent image must be mirrored and verified, and any gap blocks installation | Mirror the chart version and the exact Airflow image you plan to run, and keep a written list of dependent images |
| Kubernetes cluster readiness | Platform team | Clusters outside the supported Kubernetes range, or missing storage, ingress or policy controls, delay the install | Confirm the cluster version against the supported range (1.30 to 1.35 for Airflow 3.3.2), then agree on storage, ingress and policies |
How to confirm the Helm deployment works and fails safely
A Helm install that returns without error proves very little. This section is complete only when a written set of acceptance checks passes against the cluster your team will run. Start with readiness: the scheduler, DAG processor, API server, triggerer if enabled, and the executor components should all reach ready state, and the migration job should finish without errors. Next, confirm that the scheduler and DAG processor parse a sample DAG from the delivery path you chose, whether git-sync or DAGs baked into the image. Then run a test task on your chosen executor and confirm its logs reach the configured log destination. Finally, send an authenticated request to the API server and record the response. Keep these checks in a runbook so the same list runs after every install and upgrade.
Two checks are easy to skip and expensive to miss. The first is a deliberate pod restart. Restart the scheduler during a running DAG and confirm that task state is held in the metadata database, so the replacement pod continues the run without losing history or duplicating task instances. Airflow documents support for running more than one scheduler at the same time, using database row-level locks, so run this test on the configuration you intend to operate. Repeat the restart for the API server and confirm that sessions and DAG views recover. Record the task instance states before and after each restart. If state disappears, halt the rollout, because lost run history can break downstream pipelines and audit trails.
Failure tests show whether the deployment fails in a way your team can diagnose. For wrong database credentials, expect the migration job and the scheduler or API server pods to fail at startup, with authentication errors in their logs and restarts visible in pod events. The credentials should never appear in plain text in logs or chart output. For a broken git-sync reference, point the chart at a nonexistent branch or path. The git-sync sidecar should report clone failures, and the DAG processor should show import errors or stop refreshing DAGs. Confirm what happens to DAGs that already parsed successfully, because that behavior determines whether a bad commit halts scheduling or only blocks new changes. Document the exact messages your team sees for each case.
The worker-node test answers a different question: what happens to running work when capacity disappears. Drain or power off a node that hosts running task pods, then observe how the executor handles the orphaned tasks. With KubernetesExecutor, each task runs in its own pod, so check that the affected task instances move to a failed or up-for-retry state according to their retry settings, and that the scheduler starts replacements on remaining nodes. Confirm that a retried task does not produce a second successful run for the same logical date unless your DAG design allows it. The exact behavior depends on your executor and configuration, so confirm it in your own environment rather than assuming it.
On-call teams need a short set of signals for each failure, written before go-live. For every test, list the first alert or dashboard that fires, the Kubernetes events and container logs to open first, the Airflow views that show task and DAG state, and the expected recovery step. Assign an owner to each signal and check that alerts reach that owner outside business hours. Store the test results with the release record so auditors and the on-call rota can see what was tested, when, and against which Airflow and Kubernetes versions. Verify version compatibility against the Airflow prerequisites, which list Kubernetes 1.30 to 1.35 for the current 3.x patch release, before you accept any result.
What to monitor, back up, upgrade and document after go-live
Go-live starts the operating work for an Airflow release on Kubernetes. The cards below cover what to watch on the running components, what to protect so the release can be rebuilt, and how to change it safely over time. Each card names one responsibility so that a named team can own it before handover.
Monitor scheduler, DAG processor, API server and workers
Airflow 3 replaces the webserver with an API server and runs the DAG processor as a separate component, so each one needs its own health signal. Schedulers can run more than one replica at a time, so track heartbeats for every replica and alert when one goes silent. Confirm which metrics your Airflow version exposes and which ones your monitoring stack scrapes. Watch worker queue depth and task start latency, whether workers are Kubernetes pods or Celery workers.
Watch metadata database load
Scheduler loops, task state changes and API calls all read or write the metadata database, so its connection count, query latency and lock waits often show a problem before the UI does. Use the monitoring you already run for PostgreSQL or MySQL, and set alert thresholds from a baseline taken during the first weeks in production. Connection pooling deserves attention because each additional scheduler, API server and worker replica opens its own connections. Confirm your database version against the Airflow prerequisites before go-live.
Back up the metadata database
The metadata database holds DAG run history and task state, which cannot be regenerated from code. Connections and variables also live there unless a secrets backend holds them. Schedule regular backups, then restore one into a separate namespace on a fixed cadence and record how long the restore actually took. The Airflow production guide warns that SQLite is for testing only and can lose data, so confirm that PostgreSQL or MySQL is the backend before relying on any backup.
Back up values and secrets
A release can only be rebuilt if you keep the Helm values file, the chart version, the image tag and every secret those values reference. Store the values in version control and keep secrets in your secrets manager, referenced by name from the values. Include the Fernet key used to encrypt stored connections, because losing it leaves those connections unreadable. Test a rebuild from these artifacts in a non-production namespace before you need it.
Upgrade chart, image and Airflow together
Treat the chart version, container image and Airflow release as one set that you test and move together. Airflow 2 reached end of life on April 22, 2026 and gets no fixes, so new installs should start on Airflow 3. The Airflow 3 upgrade guide requires Airflow 2.7 or later before the move, so older 2.x installs need an intermediate step. Test each step in a non-production namespace against a recent copy of the metadata database. Upgrade mechanics are covered in the upgrades topic.
Document values, ownership and runbooks
Record which values differ from chart defaults, why each one was set and who approves changes to it. Assign a named owner for each component, including the metadata database, secrets, executor capacity and the DAG delivery repository. Write runbooks for scheduler restarts, failed database migrations, stuck workers and restores from backup, and keep them in the same repository as the values. Review the values and runbooks after every upgrade so they match the running release.
Questions teams ask before installing Airflow on Kubernetes
How much does it cost to install Airflow on Kubernetes?
The Airflow software has no license fee, since Apache Airflow is released under the Apache License 2.0 and the project offers no paid edition. The install cost comes from the work and infrastructure around it.
Engineering time covers chart values, the external metadata database, secrets, identity, logging and documentation. Cluster capacity covers the scheduler, API server, DAG processor, triggerer and workers. Managed database and storage add cost if you use them.
Most engineering effort is one-time, while infrastructure and any support arrangement recur. Costs rise with the number of environments, identity integrations and DAG delivery methods. For a fixed-scope quote, ask for an itemized scope, deliverables, assumptions about who provides the cluster and database, acceptance criteria and handover material.
How long does an Airflow Helm chart installation take?
Duration depends mostly on prerequisites and approvals, and the Helm deployment itself is usually the shortest step.
The critical path often runs through a provisioned PostgreSQL or MySQL instance, a namespace with network and image access, identity and secrets decisions, and internal change approvals. Other drivers include the number of environments (development, test and production), whether DAGs arrive by git-sync or a baked image, where logs go, and how many review cycles your change process requires.
Ask for a schedule that ties each milestone to the client input it needs. Confirm lead times for database provisioning and access approvals early, because those usually set the timeline.
What does the client need to provide before installing Airflow?
The client provides access, decisions and sign-off.
Expect to supply a Kubernetes cluster within the supported version range, a namespace where the team can deploy Helm releases, and a PostgreSQL or MySQL metadata database that is provisioned, backed up and reachable from the cluster. You also need decisions on:
- Identity: which auth manager is used and how users sign in
- Secrets: Kubernetes secrets or an external secrets backend
- Images: the container registry and image sources
- DAGs: repository access and delivery method
- Logs: destination and retention
Name a technical owner who can approve changes, and agree in writing who signs off each environment before production. Open decisions in these areas are a common reason installs stall.
Can an internal platform team install Airflow on Kubernetes alone?
Often yes, if the team already runs Helm-managed workloads on Kubernetes and operates PostgreSQL. The first install depends less on the chart than on the components it creates. In Airflow 3, the scheduler, DAG processor, API server, triggerer and workers are separate pieces, and each needs configuration, health checks and log collection.
Internal teams often find executor choice, DAG delivery, secrets handling and upgrade planning harder when they have not run Airflow before. Check three things honestly: whether someone has protected time in the schedule, whether they have hands-on Airflow experience, and whether they can own the system after go-live.
A partner can run the install alone, pair with your team, or cover only the parts you lack. DeployOpen implements inside your own infrastructure, so ownership stays with you.
Which Airflow and Kubernetes versions should a new install target?
For a new install, target Airflow 3, with 3.3.2 as the current patch release, and a Kubernetes version from 1.30 to 1.35 as listed in the Airflow 3.3.2 prerequisites. Airflow 3 was first released on April 22, 2025.
Airflow 2 reached end of life on April 22, 2026, so it receives no fixes and should not be chosen for new work.
Pair Airflow with a supported Python version and a metadata database from the prerequisites: PostgreSQL 14 to 18, or MySQL 8.0, 8.4 or an Innovation release. MariaDB is not supported, and SQLite should not be used in production. Confirm which chart release targets your Airflow version in the chart documentation, and check the provider packages you need. Re-check the version support table before go-live, because patch numbers change.
Can the official Airflow Helm chart run in an air-gapped cluster?
It can, but only after you mirror everything it pulls into registries and package sources your network can reach. The official chart uses the official Airflow Docker image, so that image needs an internal copy. Also mirror the chart package, any in-cluster PostgreSQL or MySQL image, and any sidecar images the chart uses, such as the one for git-sync.
Installing Python packages at container startup needs network access, so bake the providers you need into a custom image instead. Confirm each image and package name against the values and documentation for your chart release. Test a full install with outbound access blocked before you commit to the design.
Should we deliver DAGs with git-sync or baked container images?
Choose git-sync when DAGs change often and you want them to deploy without rebuilding images. Choose baked images when you need immutable, versioned releases that are easy to trace, promote and roll back.
Git-sync pulls DAG code from a repository into the pods, so it depends on repository access and credentials available inside the cluster. Baked images bundle DAGs and dependencies into one artifact, which simplifies audits and rollbacks, but every DAG change then goes through a build and push.
Whichever you choose, keep DAG code in version control, separate dependency installs from runtime, and test the path in a non-production environment with the same network restrictions as production. Confirm the values for each method against your chart release before writing the deployment plan.
What does an Airflow support arrangement cover after go-live?
The written agreement sets the coverage, so read its scope before signing. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope agreed in writing.
For Airflow, settle these questions in the agreement:
- Which release line you stay on as versions move through their life cycle
- Who applies patch releases and provider package updates
- How database migrations are rehearsed before production
- How incidents are raised, triaged and answered, and during which hours
- How changes to DAGs and custom code are tested
- How backups and restores are verified
Confirm what is excluded, such as major version migrations or customization work, which may be quoted separately.
How DeployOpen scopes, builds, hands over and supports Airflow on Kubernetes
DeployOpen plans and implements Apache Airflow on Kubernetes inside your own cloud accounts, data centers or air-gapped networks, using the official community Helm chart and the official Docker image. Each engagement starts with a written, fixed scope that names the Airflow version, Kubernetes version, metadata database and DAG delivery method before any cluster changes are made.
How we scope
- Confirm the target Airflow 3 patch release and the Kubernetes versions your clusters run against the published prerequisites.
- Record the metadata database choice, including PostgreSQL or MySQL, backup approach and whether an external managed instance is in use.
- Agree the DAG delivery method (git-sync or a baked image), logging destination and secrets handling in the written scope.
How we build
- Write and review Helm values files for the chart, covering executor settings, resource requests, probes and the separate DAG processor component.
- Connect Airflow to the external database, verify scheduler and API server startup, and check that DAGs load from the chosen source.
- Test task execution end to end, confirm log retrieval works, and record the results alongside the configuration in version control.
How we hand over
- Deliver the values files, deployment runbook and a list of every chart setting we changed from the defaults, with its reason.
- Walk your platform and data engineering teams through upgrade steps, rollback steps and where logs and metrics are read.
- Document the configuration state at handover so your team can reproduce the deployment in another cluster without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original build.
- Track Airflow version life cycle dates, including the Airflow 2 end-of-life date, so chart and image upgrades are planned in advance.
- Confirm which Kubernetes and database versions each Airflow upgrade supports before changing the running cluster.
