When teams run Apache Airflow on Red Hat OpenShift
Teams that have standardized on OpenShift and need scheduled data pipelines inside their own clusters can run Apache Airflow there with the community Helm chart. This section explains what that chart provides, where OpenShift adds its own decisions, and why the Airflow 3 architecture makes the chart values the first thing to plan. The chart is maintained by the Airflow community and uses the official Docker image, so the container you run is the same image the project publishes, which you can rebuild and scan on your own schedule.
OpenShift changes two parts of the default setup. The first is security context constraints: the chart creates the related RBAC objects only when rbac.createSCCRoleBinding and rbac.create are both true, so your platform team should confirm which SCC the namespace assigns and whether those flags match its policy. The second is traffic exposure: the API server needs either an OpenShift Route or a Kubernetes Ingress, and that choice determines how users and task logs reach it. Plan the non-root user, writable paths and the route hostname before the first install, not after pods fail admission.
Airflow 3 splits the old webserver into an API server started with airflow api-server, and it requires the DAG processor to run as a separate component alongside the scheduler. Each of these components needs its own deployment settings, database access and resource requests, so the values file is no longer a single-service template. Confirm the Kubernetes version you run against the Airflow 3.3.2 prerequisites (Kubernetes 1.30 to 1.35) and your OpenShift release notes, and confirm that your external PostgreSQL or MySQL version is on the supported list before you pick chart settings.
Which chart and cluster options fit your OpenShift setup
This table compares the main choices for running the Airflow Helm chart on OpenShift, with the conditions where each option fits and the trade-off it brings. Read each row against your own security policy, database estate and release process, then confirm the chart settings with your platform team before you commit.
| Decision | When it fits | Trade-off |
|---|---|---|
| SCC handling (rbac.create and rbac.createSCCRoleBinding both true) | The chart should bind its service accounts to security context constraints, so the cluster admin can review that binding | Both settings must be true for the chart to create the SCC role binding, so confirm who approves the RBAC objects it creates |
| SCC handling (either setting false) | Your cluster team manages SCC bindings outside Helm and wants the chart to create no cluster-scoped role bindings | Someone must create and maintain the binding manually, and a missing binding often shows up as pods that will not schedule |
| LocalExecutor on a single namespace | Smaller pipeline volumes where tasks can share scheduler-side resources and you want fewer moving parts | Task capacity is bounded by the scheduler pod, so scaling requires a different executor |
| KubernetesExecutor | Tasks have uneven resource needs or need isolation, and you accept a pod start for each task | Each task pod adds scheduling latency and needs its own image pull and security context, which the SCC must allow |
| Route for the API server | Your OpenShift platform team standardizes on routes and wants TLS termination managed at the router | Certificate lifecycle and router configuration sit with the platform team, so align the hostname and TLS policy early |
| Ingress for the API server | Your cluster exposes applications through Kubernetes ingress objects, or your gateway team owns the entry point | Confirm which ingress controller your cluster runs and how it maps to the OpenShift router before you build the release |
| External metadata database | You run a supported PostgreSQL or MySQL service with backups, patching and access controls you already operate | Connection secrets, network policy and database sizing become your responsibility, and the chart does not manage the database lifecycle |
| Embedded database in the chart | Only for testing or proof-of-concept work, since the chart guide calls the embedded Postgres suitable for testing only | Not appropriate for production data, so plan the move to an external database before go-live |
| PgBouncer in front of the database | Connection counts rise with workers and schedulers, and your database team wants fewer direct connections | Adds a component to patch and monitor, and the pooled connection secrets need the same handling as the database credentials |
| Images from an internal registry mirror | Your cluster pulls only from approved registries, or the environment is restricted or air-gapped | You own image mirroring, tag promotion and scanning for each Airflow release, and you must confirm the image pull secrets |
| DAG delivery baked into images | You want immutable releases and rollback tied to a single image tag | Every DAG change needs a new image build and rollout, which lengthens the release cycle |
| DAG delivery through git-sync | DAG authors need to publish changes without rebuilding the image, and your internal Git server is reachable from the cluster | Requires credentials and network access to Git, and the single-repository setup limits how you split ownership |
How security context constraints shape the Airflow install
The Airflow Helm chart creates SCC role bindings only when both rbac.createSCCRoleBinding and rbac.create are set to true, so those two values decide whether the chart asks OpenShift to attach a security context constraint to Airflow's service accounts. Before the first install, confirm which values your release sets and who in your organization can apply them. Creating RBAC objects and binding an SCC are privileged actions on OpenShift, so the person or pipeline running helm install needs permission to create role bindings in the namespace, and a cluster administrator may need to review or pre-create the binding if your policy keeps SCC decisions outside application teams. If one of the two values is false, the chart skips the binding and the pods fall back to whatever SCC the cluster already grants, which can differ from what the chart was tested against.
The SCC the cluster assigns and the user ID baked into the image must agree. OpenShift typically runs containers under an arbitrary, randomly assigned UID from a namespace range rather than a fixed user, so an image that expects a specific UID or that writes to paths owned by root can fail at startup or during log and DAG writes. Confirm the assigned SCC for each Airflow service account, confirm the UID range it permits, and test that the scheduler, API server, DAG processor, triggerer and workers can write only to the directories they need. Keep runAsNonRoot, privilege escalation disabled and dropped Linux capabilities in place, and avoid widening an SCC to fix a single permission error. The Helm chart production guide describes the chart's security settings, and each change to them should be recorded in the deployment's change log so that auditors can trace who granted what access and when.
How to install the Airflow Helm chart on OpenShift
This sequence takes an OpenShift cluster from a compatibility check to a deployed Airflow 3.3.2 API server running under the platform's security constraints. Each step closes with a check so the team knows whether to move on.
Confirm version compatibility before any install
The platform team confirms that the target cluster runs a Kubernetes version within the 1.30 to 1.35 range that Airflow 3.3.2 lists as supported, and that the Python and database versions planned for the deployment also fall within the published prerequisites. Ask the OpenShift vendor which Kubernetes release the cluster is built on, since OpenShift versions map to Kubernetes minor versions. Done when the team has written down the Airflow, Kubernetes and database versions and each one matches the prerequisites page.
Provision an external PostgreSQL metadata database
The database team creates a PostgreSQL instance within the 14 to 18 range, outside the cluster, and sizes it for the metadata workload. Do not use the embedded database from the chart, which the chart guide describes as suitable for testing only, and do not use SQLite or MariaDB, which Airflow does not support for this role. Create a dedicated database and role, and store the connection details in a Kubernetes Secret rather than in values files. Done when a test connection from a project pod succeeds and the database accepts the planned connection count.
Mirror or select the container image registry
The platform team decides where the Airflow image and any custom providers come from, then copies the official Airflow image into an internal registry the cluster can reach, especially if the cluster has restricted egress. Pin the image to the 3.3.2 tag rather than a floating tag, and confirm that the registry pull secret is linked to the service account the chart uses. Done when the cluster can pull the pinned image in a test pod and the team has recorded the image digest in the change record.
Set chart values for RBAC and security context constraints
The deployer sets rbac.create and rbac.createSCCRoleBinding to true so the chart creates the role binding that OpenShift needs to apply security context constraints. Confirm which SCC the cluster assigns to the Airflow service accounts, and ask the cluster administrator whether a custom SCC is required by policy. Keep the containers on least-privilege security contexts and avoid granting elevated SCCs to the whole namespace. Done when a dry-run render of the chart shows the expected role bindings and no privileged settings.
Expose the API server through a route or ingress
The networking team chooses between an OpenShift Route and a Kubernetes Ingress for the Airflow API server, which in Airflow 3 replaces the webserver, and sets the hostname, TLS termination and certificate source. Confirm with the platform team which option the cluster standard uses and whether the route must sit behind an internal or external load balancer. Done when the route or ingress resolves inside the network and the certificate chain validates from a client host.
Deploy the chart with the reviewed values
The deployer runs the Helm install or upgrade with the reviewed values file, pointing the chart at the external database, the mirrored image, the RBAC settings and the exposed hostname. Run the chart from a pipeline or a controlled workstation so the release, values and image digest are recorded together. Confirm that the scheduler, DAG processor, triggerer and API server deployments all reach a ready state. Done when the Helm release status reads deployed and every component reports ready.
Verify non-root pods and a responding API server
The team inspects the running pods and confirms that each container runs as a non-root user and that the security context constraint assigned to each pod is the one the team approved. Then it requests the API server health endpoint through the route or ingress and confirms a successful response. Record the pod security details and the health check output as the acceptance evidence for this deployment. Done when every pod shows a non-root user ID, the SCC annotation matches the approved policy, and the health endpoint returns a healthy status.
Routes or ingress for the Airflow API server
On OpenShift, a Route is the native way to publish an HTTP service from the cluster's router tier. The Airflow Helm chart can be configured to create an Ingress object, but your cluster must have an ingress controller that translates it into router configuration. Confirm which of these your OpenShift version and cluster configuration support before you design the exposure path, because the answer changes which objects the chart should create and who must maintain them.
- TLS termination: Routes can terminate TLS at the router, re-encrypt to the API server pod, or pass TLS through. Pick the mode before you request certificates, since re-encrypt requires a certificate the pod trusts.
- Platform ownership: The OpenShift platform team typically operates the default router and its wildcard domain, so the team needs to agree on hostnames and who adds them.
- Security context: Creating Routes does not require extra privileges for the Airflow pods, but the namespace's permissions must allow the Airflow service account to manage them, or the platform team creates them separately.
- Internal-only access: Routes can be published on an internal router shard so the API server is reachable only from the corporate network.
- Operational fit: Teams already using OpenShift tooling usually find Routes simpler to audit and to move between clusters.
Before you commit, ask the platform team which router shards exist and whether internal-only routing is available to your namespace.
A Kubernetes Ingress is the portable way to describe HTTP routing in the Airflow chart, and it works only when a suitable ingress controller is installed and selected in your cluster. Many OpenShift environments can process Ingress objects, but the supported controller, annotations and TLS behavior depend on the platform version and its configuration. Treat the controller as a dependency to confirm, not an assumption.
- TLS handling: TLS is usually terminated at the ingress controller, and the certificate is referenced through a Kubernetes Secret in the Airflow namespace.
- Annotations: Behavior such as body size limits, timeouts and rewrites is often set through controller-specific annotations, which makes the chart values less portable between clusters.
- Certificate ownership: Your team, or a certificate manager operated by the platform team, must create and renew the certificate Secret, so define that owner before go-live.
- Internal-only access: Exposure depends on which ingress class is used and on the network policy of that controller, so verify the internal class exists before relying on it.
- Portability: Ingress definitions move more easily to other Kubernetes distributions, which matters if you run Airflow in more than one environment.
Ask the platform team which ingress class is supported and who owns the controller's configuration and upgrades.
Whichever object you choose, the exposure path depends on three decisions that sit outside the Airflow chart: who manages DNS records, who issues and renews certificates, and who may reach the API server from which networks. The Airflow 3 API server also serves the user interface and the task execution endpoints, so access must be planned for both human users and workers that call it. Document these decisions in the same change record as the Helm values.
- DNS: Choose a hostname in a zone your organization controls, and record who creates the entry and how changes are reviewed.
- Certificates: Decide whether certificates come from an internal certificate authority, a managed issuer or the platform's own tooling, and who handles renewal and revocation.
- Trust: If TLS is re-encrypted or passed to the pod, the Airflow components and any clients must trust the issuing authority.
- Network scope: Limit access by corporate network, VPN or identity-aware proxy where your policy requires it, and confirm the controller or router enforces those limits.
- Authentication: Exposure does not replace sign-in. Plan the authentication manager and its redirect URLs with the hostname you publish.
Before you deploy, confirm the hostname, certificate owner and renewal process in writing with both the security and platform teams.
Exposing the API server is a shared task. The Airflow team defines the chart values and the hostname it needs, while the platform team operates the router or ingress controller, the wildcard or zone configuration and the certificate tooling. Agree on that split early, because a gap between the two teams is the most common reason a finished deployment cannot be reached or cannot be renewed. The list below sets out what each side usually needs to provide.
- Airflow team: Supplies the hostname, the required ports, the expected traffic pattern and the authentication settings.
- Platform team: Provides the router or controller, the approved domains, the ingress class or router shard and the network policy.
- Security team: Reviews TLS modes, certificate authority use, internal-only requirements and logging of access to the API server.
- Change management: Records the chart values, DNS changes and certificate installation as one reviewable change.
- Operations: Owns renewal alerts, certificate expiry monitoring and the runbook for rotating the certificate Secret or router certificate.
Request a written description of the platform team's operational duties for the chosen object, including renewal and upgrade responsibilities.
Security controls to plan before go-live
Running Airflow on OpenShift puts the scheduler, API server, DAG processor, workers and metadata database into one trust boundary, so a weak control in one place affects the rest. The cards below cover the controls to decide and verify before any production DAG runs, from pod permissions to the logs that can expose secrets.
SCC and pod security
The Helm chart uses security context constraints only when both rbac.createSCCRoleBinding and rbac.create are true, so confirm those values match your cluster policy before install. Run containers as non-root with least-privilege security contexts, and check which SCC each Airflow pod is actually admitted under. Ask your platform team whether any Airflow component needs a broader SCC than the restricted default, and record the reason if so.
Metadata and key secrets
Keep the metadata database connection, the Fernet key and the API secret key in Kubernetes Secrets rather than values files. Kubernetes Secrets are stored unencrypted in etcd by default, so confirm with your OpenShift administrators that encryption at rest is enabled for etcd before you store the Fernet key there. Plan a rotation procedure for the Fernet key, since losing or changing it without a plan can make stored encrypted connection values unreadable.
RBAC least privilege
Restrict who can list, watch and read Secrets in the Airflow namespace, because any identity that can read them can read the metadata and key material. Bind Airflow's service accounts only to the roles the chart needs, and review the bindings the chart creates before accepting them. Keep cluster-wide roles out of the namespace, and confirm that DAG authors and operators receive separate, narrower access.
Image provenance from your registry
Pull the Airflow image and any custom image from a registry your organization controls, and pin tags to a specific Airflow patch version and digest. Confirm that the OpenShift image policy allows only images from approved registries and that your scanning pipeline checks each rebuild. Ask your security team how image signatures will be verified before a new Airflow patch reaches production.
Network policy between components
Limit traffic so that only the scheduler, workers, API server, DAG processor and triggerer can reach the metadata database and each other on the ports they need. Restrict access to the API server route to the users and networks that require it, and confirm how the database is reached when it runs outside the cluster. Test the policies with a failing connection attempt from an unrelated namespace before go-live.
Log access
Task logs can contain connection details, query text and values that were printed by DAG code, so treat them as sensitive. Decide who may read logs through the API server and whether logs are stored in remote storage with its own access policy. Confirm that log retention and deletion match your data handling rules, and that pod logs collected by OpenShift logging are restricted to the same people.
External databases and image registries
Plan the metadata database before the first helm install. The Helm chart's production guide advises an external metadata database and describes the embedded Postgres as suitable for testing only. On OpenShift this means a PostgreSQL or MySQL instance you run or buy from a managed service, reached through a connection secret that the chart reads. The Airflow 3.3.2 prerequisites list 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, so a pilot on SQLite does not carry over to the cluster. Confirm the exact database versions your OpenShift platform team can supply, and confirm backup and restore ownership for that database before go-live, because the scheduler, API server and workers all depend on it.
Connection counts are the next decision. Every scheduler, API server, DAG processor, triggerer and worker pod opens its own database connections, so the count grows as you add replicas or workers. The chart guide recommends PgBouncer to reduce database connections, and the Helm chart exposes PgBouncer settings you should size against your replica counts and your database's connection limit. Some teams also need a private registry mirror: OpenShift pulls the Airflow image and any custom image from a registry you specify, so the cluster's image pull secret, the image repository and the mirror must agree on tags. Confirm with your platform team whether pulls go through an internal mirror or an allow-listed external registry, and whether the cluster can reach it in a disconnected network. Operationally, enable the databaseCleanup CronJob and set retentionDays to a value your audit and troubleshooting needs justify, since run history otherwise grows without limit.
Limits to confirm in your OpenShift environment
Several limits sit outside the Airflow chart and decide whether an install is supportable on your cluster. Check the Kubernetes range, the lifecycle of your cluster's Kubernetes minor version, how the chart and image are pinned, who maintains the chart, and the security and registry rules your platform team enforces.
Airflow Kubernetes prerequisite range
Airflow 3.3.2 lists Kubernetes 1.30 to 1.35 as supported. Match that range against the Kubernetes minor version your OpenShift release includes, and get the mapping from Red Hat in writing before you choose an Airflow release. If your cluster runs a Kubernetes minor outside the list, confirm whether a later Airflow release supports it before you upgrade the cluster. Prerequisites change between Airflow releases, so check the page for the exact version you plan to deploy.
Kubernetes minor version support windows
The Kubernetes project maintains only the three most recent minor releases, and each minor receives patches for roughly 14 months including its pre-release period. As of September 2026, 1.35 reaches end of life on February 28, 2027, 1.36 on June 28, 2027 and 1.37 on October 28, 2027. OpenShift publishes its own lifecycle, so confirm when your cluster's Kubernetes minor stops receiving fixes and schedule Airflow and cluster upgrades before that date.
Chart version pinned to image version
The community chart deploys the official Airflow image, so the chart version and the image tag must agree on the Airflow release you have tested. Pin both in your values file or GitOps repository and do not rely on chart defaults alone. At each upgrade, review the chart's default image tag, confirm your internal registry mirrors that exact tag, and compare rendered manifests with the running release. Mismatches between chart defaults and overrides can cause failed startups or migrations.
Community-maintained chart ownership
The Airflow community maintains the official Helm chart, and the project itself is open source under Apache-2.0 with no paid edition. The chart is community maintained, so any support contract comes from a vendor or partner you choose, and you should confirm exactly what it covers. Name owners before go-live for reviewing chart release notes, rebuilding the image after Airflow patch releases, and responding when an OpenShift upgrade changes a rendered resource.
SCC and registry policies to verify
The chart applies security context constraints only when both rbac.create and rbac.createSCCRoleBinding are true, so confirm your platform team allows those RBAC objects in the target namespace. Ask which SCC admits the non-root user ID the containers run as, whether writable paths for logs and temporary files are permitted, and whether the internal registry is allowed to serve the Airflow image. Also check image pull secrets and any admission rule that requires signed or scanned images, since these can block pods at install time.
Questions teams ask before running Airflow on OpenShift
What drives the cost and effort of an OpenShift Airflow install?
Scope drives cost more than the chart itself. The Airflow chart and image are free under the Apache License 2.0, so you pay for the people who design, build and verify the deployment, plus the infrastructure it runs on. The main effort drivers are the number of executors and components you run, the external metadata database you connect, how DAG code reaches the cluster, how many identity and secrets integrations you need, and how much evidence your controls require. Ask for a quote that separates one-time build work (security context constraint review, database setup, DAG delivery, testing, handover) from recurring work such as upgrades, patching and support. Confirm which Airflow and Kubernetes versions the quote assumes, since Airflow 3.3.2 lists Kubernetes 1.30 to 1.35 as supported.
How long does an OpenShift Airflow deployment take?
Duration depends on scope and integrations, not on the Helm install itself. A basic deployment with an external PostgreSQL database and one DAG delivery method is much shorter than a deployment that adds SSO, a secrets backend, remote logging, a private image registry and an air-gapped package mirror. Clusters that already have approved registries, database services and identity providers move faster because those decisions are made. Ask for a written timeline that lists each dependency, who must approve it and which milestones require your sign-off. We fix scope and timelines in writing before work starts, so the schedule should reflect your confirmed requirements rather than an estimate made in advance.
What does the work need from our platform team?
Your platform team owns the decisions that the deployment depends on. Expect to provide a namespace or project with agreed quotas, a decision on which security context constraints your cluster policy allows, access to an approved image registry, and a route or ingress pattern for the API server. You will also need a PostgreSQL service that meets the supported versions (14 to 18 for Airflow 3.3.2), network paths from the cluster to that database, and storage for logs if you keep them remotely. Identity, secrets management and DNS approvals usually sit with other teams, so name those owners early. Plan for at least one engineer who can review the Helm values and the cluster admission rules during the build.
Can an internal team deploy Airflow on OpenShift alone?
An experienced platform team can deploy Airflow on OpenShift without a partner, and the official Helm chart and production guide give a clear starting point. The harder work is the parts that surround the chart: getting security context constraints right without granting broad privileges, running as non-root, separating the API server, scheduler, DAG processor and triggerer, and proving the configuration to auditors. Teams that lack Kubernetes operations experience, or that must meet regulatory evidence requirements on a short schedule, often bring in a partner for design review and verification. Be realistic about who will carry the work after go-live, because upgrades to Airflow 3 require a different process from routine chart updates.
Do we need to upgrade from Airflow 2 before moving to OpenShift?
Yes, if you run Airflow 2 today, you should move to Airflow 2.7 or later before upgrading to Airflow 3, and Airflow 3 cannot be installed as a direct replacement for an older Airflow 2 metadata database without that step. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, so it receives no fixes. The upgrade guide recommends moving to the latest 2.x first and checking DAG code with Ruff AIR301 and AIR302 rules. Airflow 3 also replaces the webserver with an API server, requires a separate DAG processor, and removes direct database access from task code. Decide whether to upgrade in place, deploy a new cluster or migrate DAGs, because each path changes the OpenShift design.
What does ongoing operation of Airflow on OpenShift involve?
Ongoing operation covers patching, version tracking, database maintenance, observability and access reviews. Follow the Airflow release life cycle, because limited-maintenance versions receive only security and critical fixes and end-of-life versions receive none. Plan to rebuild images on each Airflow patch, keep Kubernetes within a supported range (Kubernetes 1.30 to 1.35 for Airflow 3.3.2), and track the OpenShift release that carries those versions. Routine work also includes running the database cleanup job with an agreed retention period, reviewing scheduler health, checking remote log storage and rotating the keys stored in Kubernetes Secrets. Ask any partner whether ongoing support, upgrades and testing are offered as a retainer, and what is excluded from it.
How DeployOpen scopes and delivers an Airflow OpenShift install
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apache Airflow on Red Hat OpenShift, we start from a written scope that fixes the Airflow version, the Helm chart settings, the metadata database and the cluster constraints before any build work begins.
How we scope
- Confirm the target Airflow version and its support status before choosing the Helm chart release.
- Record the OpenShift and Kubernetes versions your clusters run, checked against the Airflow prerequisites.
- Define whether security context constraints, routes or ingress, and image registries are in or out of scope.
- Agree the external PostgreSQL or MySQL setup, PgBouncer use and retention settings in the written scope.
How we build
- Install the official Helm chart with non-root security contexts and service accounts granted only the SCC they need.
- Configure the API server exposure through a route or ingress that matches your cluster's networking standards.
- Set up DAG delivery, remote logging and secrets from your own sources, not from values files in source control.
- Test scheduler failover, worker execution and upgrade steps in a non-production cluster before cutover.
How we hand over
- Deliver runbooks for installation, upgrades, database cleanup, backups and restores of the metadata database.
- Document every SCC, role binding, image source and Helm value the deployment depends on, with the reasons.
- Provide evidence of tested recovery steps and configuration baselines for your internal audit or assessment teams.
- Walk your platform and data engineering teams through operations, with the open items recorded in writing.
How we support
- Offer ongoing support, upgrade work and continuous testing as a retainer after the handover.
- Plan Airflow and Kubernetes upgrades against published support windows, with each step reviewed before rollout.
- Review Helm chart and image updates for changes to security contexts, database migrations and DAG compatibility.
- Ask for the retainer terms, response expectations and upgrade scope in writing before you commit.
