Does Apache Airflow Work in China? Data Residency, ICP & Cross-Border Rules
Apache Airflow orchestrates the pipelines that move your data, so a DAG carrying China-origin personal information offshore is itself a cross-border transfer under PIPL — a residency question, not reachability. Airflow is open-source and self-hosted: run it in-country to keep data resident.
Does Apache Airflow work in China?
Reachability is not the test — Apache Airflow is open-source and self-hosted, so the real question is where you run it and where its pipelines land your data. Airflow's job is to move and transform data between systems, so when a DAG carries China-origin data to an offshore destination, the pipeline run is itself a cross-border transfer.
That brings it under PIPL Articles 38–40 — notice, a separate consent, and a lawful transfer mechanism — and, for a critical information infrastructure operator or high-volume handler, the Cybersecurity Law's Article 39 (formerly Article 37) in-country storage duty. The data in flight routinely includes personal information, and Airflow's own metadata database holds the connection credentials and can hold PII — so that store's residency matters too.
Because Airflow is open source and self-hosted, there is a lawful lever: run it on in-country infrastructure and keep both the orchestration and the data resident. 21YunBox maps what your pipelines carry, helps you localize the engine and data in-country, and delivers any China-facing surface on ICP-filed infrastructure — no rebuild, and never any form of circumvention. Confirm the specifics with counsel.
What Apache Airflow's own documentation says about China
| Fact | Primary source |
|---|---|
| Apache Airflow is open-source, self-managed orchestration. Its documentation states: “Apache Airflow® is an open-source platform for developing, scheduling, and monitoring workflows,” and adds, “Because Airflow is open source, you're building on components developed, tested, and maintained by a global community.” Those workflows exist to move and transform data between systems. | Apache Airflow Documentation, “What is Airflow?” (airflow.apache.org), retrieved 2026-10-12 |
| You deploy and run Airflow on your own infrastructure — the residency lever. The installation docs state: “You are expected to install Airflow - all components of it - on your own,” with “The only officially supported mechanism of installation is via pip,” plus official Docker images and a Helm chart. Managed Airflow services exist from cloud providers, but the core engine is self-hosted. | Apache Airflow Documentation, “Installation” (airflow.apache.org), retrieved 2026-10-12 |
| Landing China-origin data offshore is a cross-border transfer under PIPL. When an Airflow pipeline moves personal information collected in mainland China to an offshore destination, PIPL Articles 38–40 require notice, a separate consent, and a lawful transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. | Personal Information Protection Law of the PRC, Articles 38–40, retrieved 2026-10-12 |
| Some handlers must keep China-generated data in the mainland. For a critical information infrastructure operator or high-volume handler, the Cybersecurity Law's Article 39 (formerly Article 37) requires personal information and important data generated in China to be stored in-country, with a security assessment before any export — a duty an offshore pipeline destination cannot meet. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37), retrieved 2026-10-12 |
Sources verified by the 21YunBox compliance team on 2026-10-12.
For a mainland-China data team, the first thing to settle about Apache Airflow is that the question is not whether the web UI paints quickly from Shanghai, or whether a worker can reach the scheduler. Airflow is a workflow orchestrator: its whole job is to run the pipelines that extract, transform and move your data between systems — databases, object stores, APIs, cloud warehouses. That is exactly what makes it a data-residency case rather than a speed case. A DAG is a set of instructions for carrying data from a source to a destination; when the source holds China-origin data and the destination sits offshore, the pipeline run is itself the cross-border transfer. Where the orchestrator runs, and where its pipelines land the data, is the whole question — and because Airflow is open-source software you host yourself, you get to decide both.
Apache Airflow in China at a glance
| What decides it | In Airflow's own terms — and China's law |
|---|---|
| What Airflow is — an orchestrator, not a brochure | Airflow's own documentation calls it “an open-source platform for developing, scheduling, and monitoring workflows.” Those workflows (DAGs) exist to move and transform data between systems — extract from sources, load into destinations. The tool's purpose is the movement of data, so where it runs and where it lands data is a residency question by definition. |
| The pipeline run is the transfer | The distinctive half a reachability check never sees. When a DAG reads China-origin data and writes it to an offshore destination — a warehouse, a bucket, an API in another region — that task is the cross-border transfer (数据出境). The data in flight routinely includes personal information: customer and user tables, event streams, identifiers. Moving it offshore is the regulated act, whether or not the UI is fast. |
| Secrets and PII inside Airflow itself | Airflow's metadata database stores your pipeline's connection details and variables — its docs note Airflow “uses Fernet to encrypt passwords in the connection configuration and the variable configuration.” Task logs and XComs can also carry personal data. So residency is not only about the destination warehouse; the metadata store and logs hold credentials and PII that themselves must live somewhere lawful. |
| Residency & cross-border | Landing China-collected personal information in an offshore destination is a cross-border transfer under PIPL Articles 38–40 — requiring notice, a separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). For a critical information infrastructure operator or high-volume handler, the Cybersecurity Law's Article 39 (formerly Article 37) requires China-generated personal information to be stored in the mainland. |
| Sensitive PI & the ICP door | Where the pipelines carry government IDs, financial or health records, that content can be sensitive personal information under PIPL Articles 28–29 — a risk to confirm against what your DAGs actually move. And any public, China-facing surface you stand up around Airflow — a dashboard, a data portal, an API your mainland users reach — is an internet information service carrying an ICP filing (备案) duty bound to mainland hosting. |
| Reachability is not the axis — and self-host is the lever | Whether the scheduler answers from the mainland is operational, not the compliance question. Because Airflow is open-source and self-hosted, there is a lawful lever: run the orchestrator on in-country infrastructure so the orchestration, the metadata and the data stay resident, land China-origin data in an in-country destination, and deliver any China-facing surface compliantly — the 21YunBox Optimizer — in front of what you already run. |
What it actually moves — and what lives inside it
Airflow does not hold a single dataset the way an application database does; it is the engine that moves data, and that is precisely why it is a residency question. Every DAG is a description of a flow: pull records from a source, transform them, write them to a destination. In a real data platform those destinations are frequently offshore — a cloud warehouse in another region, a managed object store, a partner API. The moment a pipeline reads tables that were collected in mainland China and writes them somewhere outside it, the pipeline has performed a cross-border transfer, and that data very often includes personal information: customer and account tables, user events, device and contact identifiers.
There is a second, quieter store that is easy to overlook. Airflow keeps a metadata database that records your DAG runs, task state and — critically — your Connections and Variables, the configuration that lets pipelines authenticate to every system they touch. Airflow’s documentation states it “uses Fernet to encrypt passwords in the connection configuration and the variable configuration.” Encryption at rest is good hygiene, but it does not change where that store sits: the connection secrets to your databases and warehouses, plus whatever personal data lands in task logs and XComs, live wherever you run the scheduler and its database. So the residency map has two layers — the data your pipelines carry, and the credentials and PII inside Airflow itself.
The doors: residency, cross-border, sensitive PI and ICP
Point Airflow’s pipelines at offshore destinations and the first door opens. The China-origin personal information the DAGs carry comes to rest abroad, which makes it a cross-border transfer (数据出境). The duty lands on you, the handler: PIPL Articles 13 and 23 require notice and a basis to collect the data, and Articles 38–40 require a transfer mechanism to send it offshore — a CAC security assessment, the CAC standard contract, or certification — with a separate consent for the overseas transfer.
For some handlers, storage is not a matter of mechanism at all — it must stay in-country. If your organization operates critical information infrastructure, or handles personal information at scale, the Cybersecurity Law’s Article 39 (formerly Article 37 — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, its substance unchanged) requires personal information and important data generated in China to be stored in the mainland, with a security assessment before any export. A pipeline whose destination is an offshore warehouse structurally cannot meet that duty.
A sharper door is the sensitivity of the data in flight. Where a DAG moves real government IDs, financial records or health data, that content can be sensitive personal information under PIPL Articles 28–29, which demand a specific purpose, heightened necessity and separate consent. And a further door follows from publishing: the moment you expose a public, China-facing surface around Airflow — a monitoring dashboard, a data-request portal, or an API your mainland users reach — that surface is an internet information service and carries an ICP filing (备案) duty bound to a mainland hosting resource.
Why a reachability check misses this
A probe from inside China can watch the Airflow UI load, or a worker pick up a task, and conclude “it works.” That answer is beside the point. The compliance exposure is not on the screen — it is in the data the pipelines move and where they move it to: the China-origin records a DAG reads, the offshore destination it writes them to, and the connection secrets and PII sitting in the metadata database and task logs. A page-load test measures none of that. It cannot see which region the destination warehouse is in, whether a separate consent was taken, whether a transfer mechanism is in place, or that a China-facing dashboard needs an ICP filing.
There is a trap specific to this kind of platform. Making an offshore pipeline merely reachable — even standing up a worker or scheduler inside China that still writes to an offshore destination — does not move any of the regulated data in-country. The task still carries China-origin data across the border every time it runs; relocating the worker without relocating the destination changes nothing about the transfer. What decides it is where the pipeline lands the data and where the orchestrator’s own store lives. That is the competitor-proof second half of the question — and it is why keeping the orchestration and the data in-country, not merely reachable, is the answer.
The lawful path — map, localize, deliver
There is a compliant way to run Apache Airflow for a mainland-China team, and because Airflow is open-source and self-hosted it sits on the platform you already use — no rebuild, no migration off Airflow.
First, map: our China compliance team inventories what your DAGs actually carry — which sources and destinations each pipeline touches, whether personal information is in flight, where the scheduler, workers and metadata database run today, what the Connections and Variables hold, and the consent and residency basis each flow relies on. We build the technical picture; the legal conclusions are settled with counsel.
Then localize: run the self-hosted Airflow orchestrator on in-country infrastructure so the scheduler, the metadata database and the connection secrets come to rest on mainland soil; land China-origin data in an in-country destination rather than an offshore warehouse; obtain the Article 13/23 notice and separate consent; treat any government IDs or financial data in the pipelines as sensitive personal information; and minimize the personal data that enters a cross-border flow in the first place, using a lawful transfer mechanism only where a transfer is truly needed. Localize means standing up a lawful, in-country data platform — never a route that ships the data offshore anyway, and never any form of circumvention.
Then deliver: any public, China-facing surface around the platform — a dashboard, a data portal, or an API your mainland users reach — is an internet information service, so it carries an ICP filing duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — in front of what you already run, so it serves your users in China legally and compliantly. 21YunBox never uses or suggests circumvention of any kind — we keep in-country what the law says must stay, deliver the rest compliantly from inside the mainland, and never move personal information across the border by stealth. 21YunBox is a compliance overlay and partner to the Airflow you already run, not a competitor to it.
None of this is a verdict that Apache Airflow is “blocked” or “illegal” in China. It is a residency-and-consent map, and which duties bite your case turns on your entity, your role under Chinese law, your data volumes, and what your pipelines actually move — worth settling the specifics with counsel before your China team’s data flows depend on it.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law (data localization, Article 39)
- China’s Personal Information Protection Law (PIPL)
- How to get an ICP filing for China
