Apache Airflow for government and public sector

Why Apache Airflow fits public sector pipelines and what changes for the agency

Apache Airflow suits agencies that run batch pipelines over citizen, benefits, statistics or justice data and need that data to stay in infrastructure the agency controls. Airflow is an Apache Software Foundation project released under the Apache License 2.0 (SPDX: Apache-2.0), and the project itself offers no paid edition. For procurement, that means the software cost is the cost of the platform work, not a license fee to a single vendor. It also means the agency, or the partner it hires, owns hosting, upgrades, secrets, access and the evidence that the platform was run as designed. Before you commit, confirm with your procurement and legal teams how open-source licensing, support contracts and any services agreement will be documented in your acquisition file.

The ownership model changes the agency's responsibilities in four concrete ways. You choose where the scheduler, workers, API server, DAG processor and metadata database run, including air-gapped segments if your data rules require them. You plan upgrades yourself: Airflow 2 reached end of life on April 22, 2026, and Airflow 3 is the line that receives new work, so any legacy pipelines need a dated migration plan. You must also choose a metadata database that the project supports for production, since SQLite is for testing only and PostgreSQL or MySQL is recommended. Finally, you assemble the audit trail for the platform yourself, so role separation, change records and recovery tests need owners from the start.

Expect the decisions to fall into three groups: who may write and promote DAGs, who may operate the platform, and who may read run logs and data. Airflow 3 uses the Simple auth manager by default and allows only one auth manager at a time, so your identity integration is a deliberate design choice rather than a default you inherit. Ask any partner to state in writing which parts of this work they perform, which artifacts they deliver, and which items remain with your staff. Authorization for independent assessment comes from your auditors or certification bodies, not from the platform or from the implementation partner, so plan the evidence to be reviewed rather than to be certified.

Which public sector requirements shape the Airflow build

This table maps each public sector requirement in the topic research to what it means for a self-hosted Airflow build, including hosting location, encryption, scanning cadence and access separation. Read each row as a question to take to your assessor, since applicability depends on your agency, data and authorization boundary.

Requirement	What it asks for	What it means for the Airflow build
NIST SP 800-53 Rev. 5 baselines	Low, moderate and high baselines of 149, 287 and 370 controls and enhancements under SP 800-53B, per the Release 5.2.0 profiles	Pick the baseline with your assessor first, then map Airflow components (scheduler, API server, DAG processor, workers, metadata database) to control families
FedRAMP scope for cloud-hosted services	Cloud products that process federal information on behalf of an agency; single-agency systems not offered as a shared service may fall outside scope	If Airflow runs in a cloud account used only by one agency, confirm with the assessor whether FedRAMP applies; shared hosting for several agencies changes the answer
CJIS Security Policy v6.1 encryption and scanning	FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit and at rest outside physically secure locations; vulnerability scanning at least monthly	Set Airflow connections, metadata database and log storage to validated crypto, and schedule scans of the Airflow images, Helm chart and host OS at least monthly
CUI on non-federal systems (NIST SP 800-171)	Agencies set CUI safeguards using NIST SP 800-171 for non-federal systems, unless the CUI category prescribes other safeguards	If pipelines carry CUI and run on contractor infrastructure, document how the Airflow hosts meet the 800-171 requirements the agency names
CMMC Level 2 cloud storage (defense contractors)	CUI in a cloud service only if FedRAMP Authorized at Moderate or higher, or equivalent requirements met	If an Airflow deployment processes defense CUI in a cloud, confirm the hosting provider's authorization status before placing DAG data or logs there
WCAG 2.1 for web interfaces	State and local government web content and apps, including contracted ones, meet WCAG 2.1 Level A and AA from 26 April 2027 (population 50,000 or more) or 26 April 2028 (smaller entities), per 28 CFR 35.200	Airflow's web UI is a government web interface when your entity is covered; ask your accessibility lead whether custom DAG views or plugin pages fall under the rule
NIS2 for public administration	Central government entities are covered regardless of size; public administration is high criticality; national security, defense and law enforcement are excluded	Confirm whether your entity is in scope and whether Member State rules extend to local bodies; scheduling for reporting and incident response then needs documented recovery and access controls
EU sovereignty and transfer rules	Personal data transfers to third countries, including remote viewing for support, need Chapter V conditions; a cloud outside the EEA counts as a transfer; some legal exposure to foreign authorities remains	Keep the Airflow metadata database, logs and worker storage inside approved regions, restrict remote support sessions from third countries, and ask counsel to review any processor subject to foreign law

Choosing between sovereign cloud, government data center and air-gapped hosting

In an agency data center, your team controls every layer, so the work is bringing the artifacts in through your own change process. Airflow is released under the Apache License 2.0, so there is no license purchase to route, but the software, its Python dependencies and its providers still have to be sourced, checked and stored inside the agency.

Container image: Pull the official Docker image into an internal registry, pin the tag, and scan it before any cluster uses it. The community Helm chart uses the same official image, so one approved artifact can serve both paths.
PyPI packages: Mirror Airflow and the provider packages you need into an internal package index, using the constraints file for the exact release you chose so builds never reach the public index.
Provider packages: Each provider for a warehouse, secrets store or identity system is a separate package with its own version. Mirror and approve each one individually.
Metadata database: Use PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release. MariaDB is not supported as a metadata database, and SQLite should not be used in production.
Kubernetes base: Airflow 3.3.2 lists Kubernetes 1.30 to 1.35, so mirror the cluster images and charts into the agency registry before installation.

Confirm with your change board which mirror, scanning and approval steps apply before the first build is started.

In an air-gapped network, nothing arrives automatically. Every container image, Python wheel, provider package and Kubernetes image crosses the boundary as a verified transfer set, and each Airflow patch release means a new transfer set. The work is building a complete, reproducible offline repository, not just downloading the packages you think you need. Plan the transfer process with the same care as the deployment itself.

Image transfer: Export the Airflow image as an archive, verify its digest on both sides of the boundary, and load it into an internal registry.
Offline Python resolution: Build a local wheel repository from the constraints file for your release, including transitive dependencies, so installs resolve without network access.
Kubernetes images: Use kubeadm config images list and kubeadm config images pull to prepare control plane images in advance, then point kubeadm init at the private registry with --image-repository.
Verification: Review and check the integrity of every package before it enters the enclave. The same discipline appears in NERC CIP-013-2, which asks for verification of software integrity and authenticity for vendor software and patches.
Upgrade cadence: Airflow 2 reached end of life on April 22, 2026, and gets no fixes. Plan Airflow 3 patch cycles as recurring transfer work with a documented rollback path.

Ask your deployment partner or internal team to write the transfer procedure, including who approves each set, before the first offline install.

Airflow 3 settings public bodies usually need to get right

Most of the hard decisions in a public-sector Airflow deployment are made in configuration, not code. The six items below cover the metadata database, Airflow 3 components, authentication, executor placement, secrets and the container supply chain, each of which an auditor or security reviewer will ask about.

Metadata database choice

Airflow stores scheduler state, run history and connections in a metadata database. The production guide recommends PostgreSQL or MySQL, and SQLite is for testing only because it can lose data in production. MariaDB is not supported. Confirm that your chosen PostgreSQL major version sits in the supported range for Airflow 3.3.2 (PostgreSQL 14 to 18), and ask who owns backup, restore testing and patching of that database inside your agency's hosting boundary.

Separate DAG processor and API server

Airflow 3 replaces the webserver with an API server started by the airflow api-server command, and the DAG processor runs as its own component. Each process needs its own deployment, resource limits and health checks, and each must be included in your change records and network diagrams. Plan how these components reach the metadata database and the DAG storage, and document which ones are exposed to users.

One auth manager at a time

Airflow 3 allows only one auth manager, selected through the auth_manager option, and it uses the Simple auth manager by default. The Simple manager is not an access model for a public body. Choose the manager that connects to your agency's identity provider before go-live, confirm how roles map to teams, and record the decision because switching later changes how every user signs in.

Executor placement in segregated networks

Choose between KubernetesExecutor and CeleryExecutor based on where workers can run. Airflow 3 no longer supports the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor, and several executors can run in one deployment since Airflow 2.10.0. Confirm that worker nodes can reach the metadata database and the approved registry without internet access, and that Kubernetes versions fall within the supported range of 1.30 to 1.35.

Secrets backend in the agency vault

Connections and variables should be read from the agency's approved secrets store rather than kept in the metadata database or DAG files. Confirm which secrets backend provider your team will use, who can write to the vault, how rotation is triggered and whether vault audit logs capture each read. Test that a failed vault call stops the task instead of falling back to a stored value.

Private container registry

The official Airflow Docker image and the community Helm chart should be pulled into a registry the agency controls, then scanned and signed under your own process before deployment. Pin the image tag to Airflow 3.3.2 or the version your change board approved, and mirror every provider package your DAGs need. Record the digest of each image so auditors can tie a running container to the approved build.

How role separation between teams is designed in Airflow 3

Role separation in Airflow 3 is a design decision you make before go-live, not a setting you switch on afterward. Four groups usually need distinct rights: platform operators who run the scheduler, API server, DAG processor and databases; DAG authors who write and change pipelines; data stewards who own datasets and approve access to them; and auditors who need read-only evidence of runs, changes and permissions. Airflow 3 uses the Simple auth manager by default, which is suitable for trying the product but not for a public body that must show who could do what. Confirm which auth manager your build will use, since Airflow allows only one at a time, set through the auth_manager option. If you choose the FAB auth manager, confirm with your provider package version how it is installed and configured, because it comes from the FAB provider rather than the core install.

Map your directory groups to Airflow roles before the first production DAG is deployed. Write the mapping as a table your security team signs off: which agency group maps to operator, author, steward or auditor, who approves each change to that mapping, and how leavers are removed. Ask the auditor group to confirm it can see run history, DAG versions and role assignments without any write rights. Keep the number of people with operator rights small and documented, since operators can reach the infrastructure beneath the UI. The DAG-level and dataset-level permissions you need for stewards should be tested with non-production accounts that mirror real group membership.

Airflow 3 also changes who can reach metadata. Task code can no longer use Airflow database sessions or models directly and must use the REST API or the Task SDK instead. For a public body this narrows the path from a pipeline to the metadata database, which is useful for audit, but it means an author's task that previously queried the database will fail until it is rewritten. Find those tasks during the upgrade review using the Ruff AIR301 and AIR302 checks described in the upgrade guide, and decide which API scopes each task identity receives. Treat the database credentials as operator-only secrets, and confirm with your team how the Task Execution API and JWT settings are configured for your version. Record each decision so the audit file shows why a given identity can read or change a given object.

How a public sector Airflow rollout runs, phase by phase

The sequence moves from agreed control scope to a handed-over, evidenced Airflow 3 deployment that the agency can operate and upgrade on its own infrastructure. Each phase closes with a written output the agency's assessor and operators can check.

Scope the system and map controls with the assessor
DeployOpen and the agency's assessor agree which systems, data classes and network zones the Airflow deployment covers, and which baseline the agency works against. The team maps the planned design to control families in the agency's chosen catalog, such as NIST SP 800-53 for federal work, and records which controls Airflow configuration satisfies and which stay with the agency's own processes. The step closes with a signed scope statement and a control mapping that the assessor has reviewed. Ask early whether the agency's authorization path requires the hosting environment to carry its own assessment, since that changes the evidence the team must collect.
Design the environment and offline mirrors
For air-gapped or restricted networks, the team designs how Python packages, container images, the Helm chart and the official Docker image reach the isolated boundary. Each artifact is pulled, checked and promoted through an internal registry and package mirror, with a record of what crossed the boundary and when. The design also settles the metadata database (PostgreSQL or MySQL, not SQLite or MariaDB), the scheduler and executor model, and where logs and DAG files live. The step closes with an architecture document and a mirror procedure that the agency's operators can run without internet access.
Build on a supported Airflow 3 release
The team installs the Airflow 3 release that is current at build time and checks it against the prerequisites for the chosen Python, database and Kubernetes versions. Airflow 3 splits the webserver into an API server and requires a separate DAG processor, so the build deploys each component on its own. Where the agency runs Kubernetes, the official Helm chart and the official image give a supported starting point, and the team pins versions rather than tracking latest. The step closes with a working staging environment, a version record and a list of the components and their supported versions for the agency's support file.
Integrate identity and secrets
The team connects the auth manager to the agency's identity provider and maps groups to Airflow roles, so that developers, operators and approvers hold separate permissions. Connections and variables are routed to the agency's approved secrets store rather than the metadata database where the agency's policy requires it. Service accounts, API tokens and break-glass access are documented and tested. The step closes when a test set of users confirms each role can do its intended tasks and nothing more, and when secret retrieval is verified in the restricted network.
Set up DAG delivery and promotion
The team defines how DAG code moves from authoring to development, test and production, including who approves each promotion and how changes are recorded. Code is checked before deployment with the Ruff AIR301 and AIR302 rules where the agency is moving from Airflow 2 code, and task code is written against the REST API or Task SDK rather than database sessions. The step closes with a documented promotion path, a tested rollback and a sample change that moves through every stage with its approval trail intact.
Migrate schedules from the current scheduler
Existing jobs from cron, a legacy batch scheduler or an earlier Airflow installation are inventoried, classified by data sensitivity and criticality, and moved in groups. Where both systems run in parallel, the team agrees which one is authoritative for each job and how outputs are reconciled, so no report is produced twice or missed. Dependencies on external systems are confirmed with their owners. The step closes with a migration register that shows each job, its owner, its cutover date and the reconciliation result, signed off by the agency's business owners.
Run the test and evidence cycle
The team runs functional tests, failover checks on the scheduler and database, restore tests from backup, and access reviews against the control mapping from the first step. Logs, configuration baselines, change records and test results are collected into an evidence folder organized by control. Known gaps are logged with owners and planned fixes. The step closes with a test report and an evidence package that the agency's assessor reviews. DeployOpen prepares this material. Independent auditors and certification bodies decide whether the evidence meets the agency's requirements.
Hand over and plan the upgrade path
The team transfers runbooks, architecture records, the mirror procedure, the role model and the evidence index to the agency's operators, and walks them through a supervised upgrade rehearsal in staging. The agency receives a calendar of Airflow support milestones, since limited-maintenance and end-of-life dates determine when security fixes stop. Ownership of each component is recorded. The step closes when the agency's operators complete a rehearsal without DeployOpen intervention, or the remaining support tasks are written down with named owners.

Planning upgrades for a deployment that runs for years

Plan the upgrade path before the first production DAG is written, because the support window closes sooner than many public bodies expect. According to the Airflow version support table, Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, after which it receives no fixes. Under the Airflow support policy, limited-maintenance versions get only security and critical bug fixes, so any Airflow 2 deployment still in service today is already on a shrinking safety net. Ask your provider how patch cadence will be covered for each version you run, who watches the release notes, and how a security fix will reach a production cluster inside your change window.

The upgrade itself has a gate. The Airflow 3 upgrade guide requires being on Airflow 2.7 or later before moving to Airflow 3, and it recommends moving to the latest 2.x first. Run the DAG code through Ruff with the AIR301 and AIR302 rules, which flag constructs that will break. Expect the code changes to matter most: in Airflow 3, task code can no longer use Airflow database sessions or models directly and must go through the REST API or Task SDK, and SubDAGs have been removed in favor of TaskGroups. The hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0, so any deployment that relies on them needs a different executor design before the move. Inventory these dependencies early, because they determine the migration effort more than the platform installation does.

Treat each upgrade as a planned change with evidence attached. Record the version you start from, the Ruff output, the test results on a staging environment that matches production, the database migration steps, and the rollback point. Public sector change boards usually ask for this record, and an auditor reviewing a long-lived deployment will look for it. Confirm during scoping who approves upgrades, how far in advance the agency must be notified of a planned change, and whether the upgrade is covered by a retainer or a separate fixed-scope engagement. The answers to those questions shape the cost of ownership far more than the software license, which is Apache-2.0 with no paid edition from the project.

Compliance evidence public bodies ask Airflow to produce

Public bodies rarely ask for a single certificate. They ask for a set of records that show who could change pipelines, what ran, how data was protected and whether recovery was tested. DeployOpen prepares these systems and evidence, but independent assessors and certification bodies issue any audit report or certification.

Access and role configuration exports

Assessors usually ask who can view, trigger, edit and administer DAGs, and how that was decided. Plan a repeatable export of the auth manager configuration and role assignments, taken on a schedule and after each change. Airflow 3 allows only one auth manager at a time, set by the auth_manager option, so confirm which manager your deployment uses before designing the export. Check that exports match your identity provider records.

Run and change logging

Evidence of scheduled work needs run history, task logs and records of configuration changes kept for the period your assessor specifies. Decide where scheduler, API server and worker logs go, who can read them and how long they are retained. Confirm that logs cannot be altered by the people whose activity they record, and that they survive the loss of a single host.

Encryption in transit and at rest

Public bodies often set the cryptographic module requirements in their own policy, such as FIPS 140-3 validated modules or AES with 256-bit keys for sensitive data. Document where Airflow connections, the metadata database, log storage and DAG bundles are encrypted, and which library or host platform provides the cryptography. Confirm with your assessor which module validation applies to each component.

Vulnerability scanning of images and packages

Keep scan results for the Airflow base image, provider packages and Python dependencies, together with the date each scan ran and how findings were resolved. Plan scans to run at least monthly if your control baseline requires it, and record exceptions with an owner and expiry. Use only images and packages you have verified inside the isolated boundary.

Change records for DAG promotion

Each DAG moved from development to production should have a traceable record: the commit, the reviewer, the test results and the approver. Keep promotion in version control with protected branches so the record is generated by the workflow rather than written afterward. Define which changes need an emergency path and how that path is reviewed later.

Backup and recovery test results

Backups of the metadata database, DAG sources and configuration only count as evidence when restores have been tested. Record the restore date, the scope tested, the time taken and any gaps found. Include the procedure for rebuilding the scheduler and workers on a clean host, since assessors often ask whether recovery works without the original server.

What public sector teams ask before hiring a partner for Airflow

What drives the cost of a self-hosted Airflow engagement in government?

The scope of work, the hosting environment and the number of integrations drive most of the cost, followed by the identity and evidence requirements your assessors expect. A deployment inside a sovereign cloud or an air-gapped network needs more preparation than one in a standard data center, because every package, container image and Helm chart must be staged across the boundary. Each integration with a data source, secrets store or identity provider adds configuration and testing. Ask any partner for a quote that lists these components separately: discovery, architecture, build, testing, documentation, handover and any recurring support. One-time work and recurring hosting or support costs should appear as different lines, so you can compare options fairly.

Does Apache Airflow itself cost anything to license?

Apache Airflow is released under the Apache License 2.0 (SPDX: Apache-2.0), and the Apache Software Foundation project does not offer a paid edition. Procurement teams can therefore record the software as open source with no license fee from the project. The costs you pay for are the infrastructure you run it on, the staff or partner time to plan, build and operate it, and any optional commercial services you choose. Confirm with your legal and procurement teams how your own policies treat open-source components, and check the license of any provider package or plugin you add separately, since those are maintained by different authors.

How long does a government Airflow deployment take?

Duration depends on the scope agreed in writing, the hosting environment, how many integrations are in scope and how quickly approvals and access are granted. A single-cluster deployment with standard identity and no air-gap is shorter than a multi-team platform that must pass an assessment inside a restricted network. Approvals from security, change advisory and procurement boards often take longer than the technical build, so include them in your planning. Ask for a timeline tied to named milestones and to the inputs the agency must supply, so delays can be traced to a specific dependency rather than to the build itself.

What must our agency provide before a partner starts work?

Most delays come from missing inputs, so agree the list before the work starts. Typical items include:

Access to the target environment, including cloud accounts, data center networks or the air-gapped enclave, with change approvals in place
Directory groups that map to Airflow roles, such as platform administrators, DAG authors and operators
A named contact for security assessment, who can confirm which controls and evidence the assessor expects
Named data owners for each pipeline, who approve data classification, retention and access

Ask the partner to put these inputs and their owners into the written scope, with a date by which each is needed.

Can our own team install and run Airflow without a partner?

Yes, many agencies run Airflow with internal staff, and the open-source license permits it. The question is capacity and continuity. Airflow 3 changed the architecture: the webserver is replaced by an API server, the DAG processor runs as a separate component, and task code must use the REST API or Task SDK instead of database sessions. Your team will also need to choose a metadata database, which should be PostgreSQL or MySQL rather than SQLite, and to plan executors and secrets handling. Assess whether you have engineers who can operate these components through staff turnover, and whether you can maintain change records and evidence for assessors. A partner can support either path, or hand over documentation and training so your team takes over operations.

How are Airflow upgrades supported after handover?

Airflow publishes a version life cycle, and that calendar should drive your upgrade plan. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, after which it receives no fixes. Limited-maintenance versions receive only security and critical bug fixes. Airflow 3 was first released on April 22, 2025, and the current patch release is 3.3.2. The Airflow 3 upgrade guide requires version 2.7 or later before upgrading and recommends checking DAG code with Ruff AIR301 and AIR302 rules. Ask any partner how upgrades are tested in a staging copy, how evidence of each change is recorded, and whether upgrade support is covered by a retainer or a separate fixed-scope piece of work.

What evidence will auditors and assessors expect from the deployment?

Assessors usually want to see how access is granted and reviewed, how changes to DAGs and configuration are approved, how logs are retained and how backups are restored. Map these needs to the control framework your agency follows, such as NIST SP 800-53 baselines, which select different numbers of controls for low, moderate and high impact systems. Airflow itself does not make a system compliant. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or authorization. Confirm early which baseline and which assessor applies to your system, and agree the evidence list before the build begins.

Does a fixed-scope engagement cover how the system is hosted?

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope should state the hosting environment, whether the system runs in your cloud accounts, data centers or an isolated network, and which components are included, such as the metadata database, executors, DAG delivery and identity integration. Ongoing support, upgrades and continuous testing are available as retainers, so recurring work is priced separately from the build. Ask for a clear statement of what is excluded, including any changes to hosting or new integrations that would need a new scope.

What to ask a partner before signing a public sector Airflow scope

Put these questions to any partner before signing, and ask for written answers that become part of the scope. Start with the air-gapped install and package verification. Ask how container images, Python packages and Helm chart artifacts are brought across the boundary, who performs the checks, and what evidence is kept for each transfer. Ask whether the partner pins a Python version within the supported range for Airflow 3.3.2 (Python 3.10 to 3.14) and which PostgreSQL major version (14 to 18) the metadata database will run on. Ask how the scope handles the supply chain control in NERC CIP-013-2 if your organization is in that sector, since it asks for verification of software integrity and authenticity. Confirm that the scope names the specific artifacts, not a general promise to "review packages."

Next, pin down the version and support dates the scope assumes. Airflow 2 reached end of life on April 22, 2026, so a scope that starts from Airflow 2 needs a named migration path and an explicit statement of who receives fixes in the interim. Ask whether the scope targets the 3.x line, which patch release it starts from, and how the partner will record the upgrade of the Helm chart and the official Docker image alongside Airflow itself. Then settle upgrade ownership and patch intake in writing: who monitors advisories, who approves a patch for the isolated network, how long an emergency fix takes to reach production, and whether those responsibilities sit with the partner, your team or a retainer. For role mapping and audit exports, ask which auth manager is configured, how roles map from your directory, and in what format logs and access records are delivered to your audit function.

Finally, separate fixed-scope work from retainer work and ask how each is priced. A quote follows from the written scope, so ask the partner to list every deliverable, the acceptance test for each, and which items recur after go-live, such as patching, backups and restore tests. For sovereignty, ask the partner to identify every component that touches a cloud service, including telemetry, licensing checks, container registries and hosted identity providers, and to state where the data and operators sit. Ask how third-country access exposure is assessed for each one, using the EDPB Recommendations 01/2020 framework where personal data is involved. Confirm in writing that any cloud component outside your control is either removed from scope or documented with its assessment, and that your legal team reviews that document before work starts.

How DeployOpen scopes and delivers public sector Airflow work

DeployOpen plans, implements, hardens, documents and supports self-hosted Airflow inside the agency's own infrastructure, whether that is a government cloud account, a data center or an air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Written scope names the hosting model, whether sovereign cloud, data center or air-gapped, and who operates each environment.
Scope lists which Airflow 3 components are in, including API server, scheduler, DAG processor, workers and executor choice.
Scope records the controls evidence the agency needs, such as access, logging, change and recovery records, before any build starts.
We confirm the package and image sourcing process for an isolated boundary, so every dependency is known before it is carried in.

How we build

Build covers the metadata database, normally PostgreSQL or MySQL, with SQLite excluded from anything beyond testing.
Authentication is configured through the auth manager the agency selects, with role separation between platform, DAG author and operator teams.
DAG delivery, secrets handling and log storage are designed for the restricted network and tested end to end before go-live.
Testing covers scheduler failover, worker behavior, backup restore and the DAG code checks used before each promotion.

How we hand over

Handover includes documentation of the deployed architecture, configuration, network paths and the components each team owns.
Runbooks cover upgrades, database cleanup, backup and restore, and how to respond when scheduled runs stop or go missing.
Evidence packs list the configuration, access and change records prepared for the agency's own assessors, with the auditor's role kept separate.
Operators are trained on the procedures and on the upgrade path from the current Airflow line to later releases.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped to the agency's release and change calendar.
Upgrade work follows the published Airflow support windows, so the agency can plan moves before a line reaches end of life.
Security testing of the deployment, including its APIs and the hosting environment, can be scoped as a separate written engagement.
Support scope, response expectations and the handling of vendor and standard changes are confirmed in the written agreement.