Why Apache Airflow for manufacturing data pipelines
A plant or industrial company that needs scheduled data loads from ERP, MES and quality systems, plus data from its sites, can run Apache Airflow for manufacturing workloads on infrastructure it controls, so production data does not have to move into a third-party cloud to be scheduled. Apache Airflow is an Apache Software Foundation project released under the Apache License 2.0, and Airflow 3 is the current major line, first released on April 22, 2025, with 3.3.2 as the current patch release. For batch orchestration of nightly ERP extracts, quality data loads and production reporting, Airflow 3 fits the job well. The harder planning work sits around it: where workers run, how the network is segmented, and who may reach which system.
In practice, the design question is less about DAG code and more about placement. Airflow 3 separates the API server from the DAG processor and the scheduler, and the executor choice decides where tasks actually run. The Airflow executor documentation lists EdgeExecutor among the options, which is the usual starting point when workers must sit at a site and report back over HTTPS instead of opening inbound paths into the plant network. Before any build starts, confirm with your own OT and IT teams which zones can host workers, which connections are allowed outbound, and whether the metadata database can stay inside the corporate zone. Those answers shape the architecture far more than the number of pipelines.
This page sets out how to plan that build. It covers the segmentation and edge worker pattern, the scheduling of ERP and quality loads, the standards that frame OT security, and the recovery requirements for production reporting. Treat each of these as a decision to make with your plant engineers, your security team and your ERP owners before the first environment is provisioned. A clear answer on those decisions is what separates a pipeline that runs reliably at the site from one that depends on a single engineer who knows the network.
Manufacturing requirements that shape an Airflow build
This table maps each manufacturing requirement to its source and to the architecture decision it forces on an Airflow build. Read the first column as the obligation, then check the last column for where the scheduler, metadata database, edge workers and audit records should sit. The main takeaway is that the OT boundary and the reporting clock should be designed before any DAG is written.
| Requirement and source | What it asks for | What it means for the Airflow architecture |
|---|---|---|
| ISA/IEC 62443 zones and conduits (ISA/IEC 62443 series) | Group industrial control assets into zones, control the conduits between them, and assign a target security level to each zone. | Keep the scheduler, metadata database and API server in the enterprise or IT zone. Treat any path into a production zone as a conduit with a named owner and an allow list. |
| ISA-62443-3-2-2020 risk assessment for system design | Assess risk for the system design and document zones and conduits from that assessment before deployment. | Record which DAGs touch plant data, which workers reach which sites, and which credentials each worker holds. This inventory becomes the input to the zone diagram. |
| ISA-62443-3-3-2013 system security requirements and security levels | Define security requirements for each zone and conduit and set the target security level for each. | Set the target level for the Airflow control plane and for each edge worker separately. Confirm with your own asset owner which level applies to the data path. |
| ANSI/ISA-62443-2-1-2024 asset owner program | Require the asset owner to run a security program covering people, procedures and monitoring of industrial control systems. | Assign owners for DAG changes, worker patching and log review. Make DAG promotion and access reviews part of the plant change process rather than a separate IT task. |
| NIST SP 800-82 Rev. 3 (September 2023) OT security | Guides OT security covering SCADA, DCS, PLCs and building systems, and states that OT performance, reliability and safety come first. | Design so that a failed Airflow run never blocks a control function. Read-only pulls from historians or MES should be scheduled outside control loops, with timeouts and retries that do not load plant systems. |
| NIS2 Annex II manufacturing scope (Directive (EU) 2022/2555) | Lists manufacturing divisions NACE Rev. 2 26 to 30 and medical devices as a critical sector. Confirm with counsel whether your entity is in scope and whether it is essential or important. | If in scope, keep Airflow logs, DAG run history and worker access records retained and exportable so they can support incident timelines. |
| NIS2 Article 23(4) incident reporting timelines | Significant incidents require an early warning within 24 hours, a notification within 72 hours and a final report within one month. | Set up alerts for failed credential use, unexpected worker connections and DAG changes that reach OT-adjacent data. The scheduler logs must be available quickly enough to meet the 24-hour early warning. |
| Cyber Resilience Act Article 14 reporting (Regulation (EU) 2024/2847) | Manufacturers must report actively exploited vulnerabilities and severe incidents in products with digital elements, with Article 14 applying from 11 September 2026. Confirm whether your own products or firmware fall in scope. | Airflow itself is open source, but any product you ship that embeds or depends on pipeline components needs a vulnerability intake path. Track Airflow security notices and the support table for your version. |
| Machinery Regulation essential requirement 1.1.9 (Regulation (EU) 2023/1230) | From 14 January 2027, machinery must be protected so that connecting another or remote device does not lead to a hazardous situation. | Do not let a remote worker or pipeline write setpoints or commands to machinery. Limit edge workers to read or staging operations, and document this as part of the machinery risk file. |
| 21 CFR Part 11 electronic records and signatures (eCFR) | Where regulated product or batch records are involved, requires controls on electronic records, audit trails and electronic signatures. | Scheduled loads of batch or quality records need an audit trail of who changed the DAG, when each run executed and what data it wrote. Validate the workflow with your quality unit before using it for regulated records. |
How edge workers reach the plant over HTTPS
This sequence shows how site data reaches central Airflow over outbound HTTPS only, with no inbound path into operational technology. It covers the edge workers, the Airflow 3 components in the central zone, the Task Execution API, and the staging area that holds site data before the warehouse.
Map each site data flow and its direction
List every site system that produces data for the warehouse or ERP, such as historians, quality stations and batch record exports. For each source, record the owner, the data format, the expected volume, and which side starts the transfer. Ask plant engineering which sources can be reached from the IT zone at all. This step is done when every flow has a named owner, a direction and an agreed trigger, and the OT team confirms that no flow needs a route from the central zone into the control network.
Deploy edge workers inside each site zone
Place an edge worker at each site, running the EdgeExecutor, in the network segment the site team agrees to. The worker runs tasks locally and communicates with the central deployment over HTTPS. Before you fix any firewall rules, read the executor documentation to confirm how the worker connects, what it requests, and how it reports task state. The step is complete when a test worker registers with the central deployment and reports task state in a non-production environment.
Confirm outbound-only network paths with OT
Work with the OT team to define one outbound HTTPS path per site, from the edge worker to the central endpoint. Document the source host, destination, port and how the worker trusts the server certificate. Nothing should initiate a connection from the central zone into site addresses. Apply the zones and conduits thinking from the ISA/IEC 62443 series when you agree the boundary. The output is a change record approved by both OT and IT security, plus a test showing that an inbound attempt from central to a site address is blocked.
Separate the Airflow 3 control plane components
In Airflow 3, the API server replaces the webserver and starts with airflow api-server. The DAG processor must run as its own component, and the scheduler can run more than one instance at once. Keep all of these in the central zone, and point them at a PostgreSQL or MySQL metadata database, because SQLite is not suitable for production. Confirm the database versions against the prerequisites for your Airflow release. The step is complete when each component runs as a separate process and only central components can reach the metadata database.
Scope what workers can call
Task code cannot use Airflow database sessions or models directly. Workers reach the platform through the REST API and the Task SDK, and the Task Execution API governs which calls a worker can make. Review the permitted calls with your security owner and record the list for each queue. Then run a test DAG that attempts an action outside that list and confirm in your version that the platform blocks it. The output is a reviewed list of allowed worker actions and a test result for the blocked action.
Land site data in a staging zone
Edge tasks write raw site files or messages to a staging area in the central zone, such as an object store bucket or a landing schema. Downstream DAG tasks validate the staged data and only then load it into warehouse tables. This keeps raw site data separate from curated tables and gives you a point to check data before it is loaded. Confirm the staging technology, access rules and retention with your data owner. The output is a staging location with access controls, and a load DAG that reads only files that passed validation.
Test one site end to end before expanding
Run one site through the full path using a non-production dataset: worker task pickup, task execution, the staging write and the warehouse load. Check the Airflow task logs and states, the staging contents, and network logs that show only outbound HTTPS from the site. Record a pass or fail for each step and the reason for any failure. The output is a dated test record and a decision, agreed by IT and OT, on whether to add the next site.
Which Airflow modules and integrations matter on the plant floor
A plant deployment of Airflow spans the sites that produce data, the ERP and quality systems that receive it, and the IT estate that controls access. The cards below cover the components that connect those three areas and the decisions to settle before the build starts.
Executor choice for remote sites
The executor decides where tasks run. EdgeExecutor is designed for workers that sit at remote sites and reach the central Airflow over HTTPS, which fits plants with limited connectivity to the core network. KubernetesExecutor suits central compute for ERP and quality loads. Since Airflow 2.10.0, several executors can run in one deployment, so a plant can route site collection and central loads separately. Confirm each site's outbound connectivity and worker placement before choosing.
Metadata database on PostgreSQL
The metadata database stores DAG runs, task state and connections. The prerequisites list PostgreSQL 14 to 18 for Airflow 3.3.2, and the production guide advises against the default SQLite backend because it is intended for testing and can lead to data loss. MariaDB is not supported. Plan backups and restore tests for this database, since production reporting depends on its state. Confirm the chosen PostgreSQL version against the prerequisites page before provisioning.
Scheduler high availability
Airflow supports running more than one scheduler at the same time, coordinating through database row-level locks. For a plant that reports production numbers each shift, a second scheduler removes a single point of failure in the scheduling layer. Test failover on a staging copy, and confirm that the database itself is highly available, because the schedulers depend on it.
DAG delivery from controlled Git
Plant pipelines change when ERP fields, machine tags or quality specifications change, so DAG code needs the same change control as other production software. Deliver DAGs from a Git repository your organization controls, with reviewed merges and promotion from a test environment to production. Ruff rules AIR301 and AIR302 help catch Airflow 3 incompatibilities before a DAG reaches a site worker.
Plant and ERP credentials in a vault
Plant historians, MES databases and ERP APIs each need credentials that Airflow uses to pull or push data. Store them in a secrets backend your organization already runs rather than in DAG files or connection exports. Assign one service identity per integration so that a rotated credential at one site does not break others. Ask the OT and ERP owners who holds each credential and how rotation is scheduled.
SSO and the auth manager
Airflow 3 uses the Simple auth manager by default and allows only one auth manager at a time, set through the auth_manager option. The FAB auth manager comes from the FAB provider. Choose the manager that matches the identity provider the IT estate already uses, and map roles so that plant engineers see their own pipelines and central teams hold administrative rights. Airflow 2 reached end of life on April 22, 2026, so a plant still on Airflow 2 should plan its move to Airflow 3 with the auth change included.
Scheduling ERP and quality data loads
How do I make a nightly ERP load wait for the shift close data?
Model the shift close as an upstream task in the same DAG or as a separate DAG that the nightly load depends on, and use a sensor or dataset-style trigger so the load starts only when the shift close has landed. Avoid fixed clock times as the only trigger, because a late shift close will then load incomplete data without any error. In Airflow 3, cross-DAG dependencies are the place to be explicit about what the load expects, including the batch identifier or business date it reads. Ask your team to define a timeout for the wait and an alert for when it expires, so a missing shift close is visible to operations rather than discovered in the morning report. Confirm the exact dependency mechanism you want against the Airflow documentation for your planned version before the design is fixed.
How should retries and backfills work for missed ERP or quality loads?
Set retries at the task level for transient failures such as a dropped connection to the ERP API, and keep them short enough that a genuine outage fails loudly. Use retries for transient errors only, and send persistent failures to an alert, not to an endless retry loop. For missed loads, design each task to be idempotent for a given business date, so re-running a date replaces that date's rows rather than appending duplicates. Then use backfill runs for the affected dates in a controlled order, with a limit on parallel runs so the ERP and historian are not overloaded. Your engineers should test one re-run in staging before the first production backfill. Expect this design work to be a larger share of effort than the DAG code itself.
Where should data quality checks sit before a production report publishes?
Put the checks between the load and the publish step, so the report only refreshes after the data passes. Typical checks for ERP order, inventory and quality batch data include row counts against the source for the business date, null checks on keys such as batch or work order identifiers, range checks on quantities and measurements, and reconciliation totals for stock movements. If a check fails, the publish task should stop and the previous report should remain visible with a clear status. Keep the thresholds in version-controlled configuration that quality and plant owners can review. Your quality team should own the rules, while the platform team owns how they run and where failures are recorded.
Why does Airflow 3 task code use the REST API or Task SDK instead of the metadata database?
In Airflow 3, task code can no longer open Airflow database sessions or use Airflow models directly. Tasks read and write Airflow state through the REST API or the Task SDK, which keeps workers from holding database credentials and limits what a DAG author can change in the metadata database. For manufacturing, this matters because pipeline code often runs close to plant data, so a narrower path to the metadata store reduces risk. If your existing DAGs query the metadata database, they will need rework before upgrading, and the Airflow 3 upgrade guide lists the changes to check with Ruff rules AIR301 and AIR302. Plan that rework as part of the migration scope, not as an afterthought.
Can we schedule ERP and quality loads without coding Airflow ourselves?
Your team can run this work in-house if it has Python engineers who know Airflow, the ERP's data access model and the quality system's schema. A partner's work usually covers the DAG design, dependency rules, retry and backfill policy, check definitions and the runbook for re-runs, delivered under a written scope. Ask any provider to show how they handle a failed shift close, a partial ERP extract and a backfill across a month-end, because those cases reveal most of the design. The recurring part is operating the schedule, updating DAGs when the ERP changes and keeping the Airflow version supported. Airflow 2 reached end of life on April 22, 2026, so budget for an upgrade path rather than a one-time build.
What does scheduling ERP and quality loads cost, and what drives it?
Apache Airflow itself is licensed under Apache-2.0 with no paid edition from the project, so the cost is the infrastructure, the engineering effort and the ongoing operation. The main drivers are the number of source systems, the complexity of the dependencies between shift, production and month-end loads, the number of quality checks and how many plant sites share one scheduler. Infrastructure is recurring, and the metadata database should be PostgreSQL or MySQL rather than SQLite for production. When requesting a quote, ask for the scope of sources and checks, the dependency and backfill rules, the environments (development, staging and production), the upgrade and support model, and which items are one-time versus recurring. DeployOpen provides a quote from a written scope and does not publish a price list.
How long does it take to put these loads into production?
Duration depends on how many ERP and quality sources are in scope, how stable their interfaces are, how many dependencies the schedule has and how much validation the plant owners require before go-live. The first load is usually the slowest because the data contracts and check rules must be agreed with the people who own the data. Parallel runs against the existing manual or legacy process are often part of the plan, so the team can compare outputs before cutover. No duration is set here because none has been supplied for this work, so ask for a timeline in the written scope, tied to named source systems and a parallel-run period.
Rolling out Airflow to one plant before the rest
This sequence proves the edge collection, ERP loads and cutover on one site, so the remaining plants extend a pattern that has already run in production rather than a design that has only been tested on paper.
Assess scope and network zones
DeployOpen works with your OT, IT and plant teams to inventory the pilot site's data sources, the ERP and quality systems involved, and the network zones each flow crosses. The assessment records which segments may carry traffic outbound over HTTPS, which systems stay out of reach of the scheduler, and who approves each firewall change. The step closes with a signed scope document that names the pilot site, one edge worker, one ERP feed and the owners of each system. Durations depend on the agreed scope.
Confirm Airflow 3 upgrade readiness
If any existing Airflow 2 environment is part of the plant's history, the team first confirms it runs Airflow 2.7 or later, since the Airflow 3 upgrade guide requires that baseline before an upgrade. DeployOpen then runs the Ruff AIR301 and AIR302 rules over every DAG in the pilot set and records the findings. Code that uses database sessions or models directly from task code is reworked to use the REST API or Task SDK. The step closes when the rule pass is clean or each remaining finding has a documented fix and owner.
Build the single-site pilot
The team deploys Airflow 3 with a PostgreSQL metadata database, an API server, a separate DAG processor and one edge worker placed at the pilot site. The worker connects back over HTTPS, and the single ERP feed is scheduled as a DAG with secrets held in your vault rather than in DAG files. Logs, backups and access for the pilot are configured at this stage. The step closes when the edge worker completes a test run of the ERP feed end to end and the restore of the metadata database has been rehearsed.
Promote DAGs through staging
Every pilot DAG moves from a development environment to a staging environment and then to production through your change process, with each promotion recorded against a versioned commit. DeployOpen helps you define the test cases for the ERP load, including row counts, reconciliation against the source extract and failure handling when the plant network drops. Production promotion is approved by the owner of the ERP data. The step closes when the staged run matches the expected output and the change record is complete.
Cut over from existing scheduled jobs
The pilot feed runs in parallel with the existing cron or plant scheduler for an agreed period, and the team compares outputs each cycle. Once the results match, the old job is disabled in a planned change window with a documented rollback path. Ownership of any remaining legacy jobs is recorded so nothing runs twice or silently stops. The step closes when the existing job is retired, the comparison record is signed off by production reporting, and the rollback steps have been written down and tested.
Review the pilot before extending
The team reviews the pilot against the scope document, including edge worker availability during network interruptions, ERP load timing, alert routing and recovery time for production reports. Findings are split into fixes applied to the pilot and template changes for the next site. Your network and OT owners confirm the zone model still holds. The step closes with a written pilot review that is accepted before any second site is added.
Extend to further sites
Each additional plant follows the same zone assessment, edge worker placement, staging promotion and cutover steps, using the pilot's templates for DAGs, network rules and runbooks. Plants can be scheduled one at a time so production reporting stays stable throughout. Your team owns the rollout calendar and the approval for each site. The step closes when each site's feeds run from Airflow and the pilot review actions are carried into the standard template.
Compliance and evidence for manufacturing pipelines
Manufacturers face several overlapping rules that touch the data pipelines Airflow runs, from cyber incident reporting to records of production data. DeployOpen prepares the controls, logs and evidence these rules ask for, but independent auditors and certification bodies decide whether the organization meets them.
NIS2 incident reporting timelines
Manufacturing is a critical sector under NIS2 Annex II, and in-scope entities must send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Airflow pipelines that feed plant or ERP data should have run logs, failure alerts and retained task history that let your team reconstruct an incident within those windows. Confirm with counsel which entity category applies to your organization.
NIS2 fines for important entities
Important entities under NIS2 face fines of at least EUR 7 million or 1.4% of worldwide turnover under Article 34(5). The exposure is a reason to document who owns each scheduled pipeline, how failed loads are escalated and how changes to DAG code are reviewed before they reach production. Ask your legal team how the fine basis applies to your group structure.
CRA Article 14 reporting obligations
The Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents under Article 14, and those obligations have applied since 11 September 2026. For Airflow-based pipelines, this means knowing which connected products and firmware data flows you would need to report on, and keeping a current inventory of Airflow versions and provider packages. Confirm which products fall in scope before the general application date.
Machinery Regulation connection requirement
Annex III, 1.1.9 of the Machinery Regulation requires that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation. It applies from 14 January 2027. Where Airflow edge workers pull data from machines over HTTPS, the design should keep those connections one-way where possible, separate from control functions, and documented in your risk assessment. Confirm the requirement with your notified body or conformity assessment advisor.
21 CFR Part 11 electronic records
Plants producing regulated products may need production and quality records kept under 21 CFR Part 11, which covers electronic records and electronic signatures. If Airflow moves batch records or quality results, the evidence should show who changed a pipeline, when each run executed and whether records were altered. Confirm with your quality unit which records fall under the rule and how validation of the pipelines will be handled.
CMMC levels for defense data
CMMC under 32 CFR Part 170 sets three levels for defense contractors, with Level 1 covering 15 FAR 52.204-21 safeguarding requirements, Level 2 covering the 110 requirements of NIST SP 800-171 Rev. 2 for CUI and Level 3 adding 24 selected NIST SP 800-172 requirements. Where Airflow handles defense contract data, the level you need determines how access, logging and encryption are built. The Department of War suspended CMMC Phase II requirements on 13 July 2026, so confirm current contract clauses with your contracting officer.
What changes for plant IT and OT teams
The biggest change for a plant is that Airflow becomes a shared service that sits across the boundary between IT and OT, so ownership has to be written down before the first DAG runs. In a typical split, IT owns the Airflow platform, the metadata database, upgrades and backups; the data team owns DAG code and its tests; plant engineering owns the meaning of the site data and the edge workers that read it; and OT security owns the rules for what may cross the segmentation boundary. The edge workers belong to plant engineering with IT support, because they sit on the plant side of the network, see the local historian and PLC-adjacent sources, and must keep running when the corporate link is slow. Confirm this split with each team in writing, including who approves a firewall change for the HTTPS path from each site to the central scheduler.
Change control for DAGs needs the same discipline as a change to a production interface. Each DAG that loads ERP or quality data should be versioned in Git, promoted through a non-production environment, and approved by the data owner before it is deployed to the scheduler. Airflow 3 changes how code runs: task code uses the REST API or Task SDK rather than database sessions, and the DAG processor is a separate component, so IT should test a DAG change against the same Airflow version that runs in production. Ask the data team to show the Ruff AIR301 and AIR302 check results for each release, and record which DAGs can write to ERP or quality systems so that a schedule change is traceable to a named person.
Recovery for production reporting depends on the metadata database, which holds DAG run history, task state and connection references. Back up the PostgreSQL or MySQL instance on a schedule, keep copies outside the plant segment, and restore them into a separate environment at least on a planned cadence, because an untested backup does not show that a shift report can be rebuilt. The restore test should confirm that the scheduler can resume, that edge workers reconnect over HTTPS, and that missed loads can be rerun without duplicating records. Ask your team to agree on a recovery target for each reporting process and to document which source systems must be replayed after an outage. Those answers determine the backup design more than the tooling does.
What manufacturing teams ask before hiring a partner
What drives the cost and effort of a self-hosted Airflow for plants?
The scope drives it more than the software, which is free under the Apache License 2.0 and has no paid edition from the project itself. The main factors are the number of sites, how many edge workers you need, how many source systems and ERP or quality databases feed the DAGs, and how long network and OT security approvals take. Each site adds connectivity testing, worker configuration and sign-off. Ask any partner for a written quote that lists each site, source system and network path separately, and separate one-time build work from recurring upkeep such as upgrades, patching and monitoring. Hosting costs in your own infrastructure are paid to your infrastructure providers, not to the partner.
How long does a pilot take for a single plant?
A pilot's length depends on its scope, and no fixed duration applies to every plant. A pilot covering one site, a few edge workers, one ERP load and one quality data feed moves faster than one that needs new firewall rules, a separate segment for the edge workers and approval from OT and security teams. Agree the pilot's success criteria, such as which schedules must run reliably and which recovery steps must be tested, before work starts. Most engagements are fixed-scope, so the timeline is written into the agreed scope, and any partner should be able to show how each approval step affects it.
What must the plant team provide before the build starts?
The plant team provides the knowledge and access the build depends on. Typical items include a list of sites and the data each one produces, network diagrams showing which segments can reach the central Airflow, the ERP and quality systems and their owners, service accounts with least-privilege access, and the schedules that must keep running during a cutover. Plant staff should also name a person who approves changes to production reporting and a contact for maintenance windows. Confirm each item with your own OT and IT teams before the scope is signed, because missing approvals are a common cause of delay.
Can an internal team run Airflow for manufacturing data alone?
An internal team can run Airflow alone if it has engineers who can operate Linux, containers or Kubernetes, PostgreSQL, identity integration and network security, and if it owns on-call duties for scheduled production reporting. Airflow itself is open source, so the decision rests on skills and capacity rather than licensing. Teams often start with a partner for design, hardening and the first DAG deliveries, then take over operations with documented runbooks. Ask a partner which parts of the handover they cover and what your team must staff afterward.
Which Airflow version should a new plant deployment use?
New deployments should use Airflow 3, which was first released on April 22, 2025, with the current patch release at 3.3.2. Airflow 2 reached end of life on April 22, 2026, so it receives no fixes and should not be chosen for a new build. Confirm the supported Python, PostgreSQL and Kubernetes versions against the prerequisites page before you plan the host images, since your edge and central hosts may need different base images.
What recurring work follows go-live, including upgrades?
Recurring work includes applying patch releases, testing DAG code against new Airflow versions, rotating credentials, reviewing access, checking backups and restore tests, and watching scheduler health. Airflow 3 requires the API server and DAG processor to run as separate components, and the upgrade guide advises checking DAG code with Ruff AIR301 and AIR302 rules before moving. Plan upgrades before the current version leaves support. Limited-maintenance versions receive only security and critical fixes, and end-of-life versions receive none. Ask any partner for a written upgrade plan and a retainer quote that covers this recurring work.
Does the plant data path meet OT security expectations?
The design should keep edge workers in a segment that reaches the central Airflow over HTTPS only where approved, and keep the OT control network out of the Airflow data path. Security programs for industrial systems generally follow the ISA/IEC 62443 series, which groups requirements into general, policies and procedures, system and component areas. Confirm with your OT security lead which zone and conduit rules apply to each site. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so independent auditors remain responsible for formal assessments.
How DeployOpen scopes Airflow for manufacturing
DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Airflow inside your own infrastructure, including plant-adjacent and segmented networks. We start from a written scope that names the sites, data sources, schedules and network zones involved, then build and hand over against that scope.
How we scope
- Inventory the sites, ERP and quality systems, and data sources that feed each pipeline
- Map which network zones and edge links each DAG crosses before any build begins
- Agree the Airflow 3 version, executors, metadata database and recovery targets in writing
- Record the identity, secrets and logging decisions the written scope depends on
How we build
- Deploy the scheduler, DAG processor, API server and workers in the environments you designate
- Configure edge workers to reach the control plane over HTTPS through approved paths
- Build and test DAGs for ERP and quality loads with staging runs and repeatable data checks
- Verify failure handling, retries and alerting against scenarios agreed during scoping
How we hand over
- Document architecture, network flows, DAG delivery steps and the configuration of each component
- Provide runbooks for restarts, backups, restores and Airflow version upgrades
- Deliver a record of tests, access settings and change steps your auditors and OT staff can review
- Walk your operations and plant IT teams through the handover before the engagement closes
How we support
- Support is available as a retainer covering patching, upgrades and continuous review of the deployment
- Plan Airflow upgrades against the official support table so you stay on supported releases
- Review access, secrets and logs on a schedule set in the retainer terms
- Confirm current prerequisites and supported releases with your team before each change window
