Does Apollo GraphQL Work in China? Data Residency, ICP & Cross-Border Rules
Apollo's GraphOS platform — schema registry, usage metrics and Studio — is a US-hosted SaaS control plane that receives your GraphQL schema and per-operation telemetry, so using it from China is a PIPL cross-border transfer, not a speed test. The self-hosted Apollo Router can run offline in-country to keep them resident.
Does Apollo GraphQL work in China?
Whether Apollo GraphQL works in China is a data-residency question about your schema and operation telemetry, not whether Studio loads from Shanghai.
Apollo's GraphOS platform — the schema registry, usage metrics and Studio — is a SaaS control plane. By Apollo's own data-privacy documentation it receives your registered GraphQL schema and, from the GraphOS Router, "the normalized query operation string for every executed operation" plus per-resolver timing, and it "processes and stores data in the United States" with no mainland-China region. Sending that schema shape and per-operation telemetry — which expose your API surface and, through field-level usage, user-data patterns — to an offshore control plane is a cross-border transfer PIPL governs.
Your query results never reach Apollo, but the schema and usage telemetry do. The lawful lever is Apollo's own self-hosted Router run offline in-country — keeping the schema and telemetry resident — in front of (or in place of) the offshore GraphOS control plane.
What Apollo GraphQL's own documentation says about China
| Fact | Primary source |
|---|---|
| In Apollo's own words: GraphOS receives "Schema registration via schema reporting" and, from the GraphOS Router, "The normalized query operation string for every executed operation" with per-resolver timing — and "Apollo processes and stores data in the United States," with no mainland-China region. Your graph's "operation results never even reach any Apollo-managed service," but the schema shape and operation telemetry do. | Apollo — GraphOS Data Privacy and Compliance, retrieved 2026-10-13 |
| The self-hosted Apollo Router runs in your own infrastructure, and Apollo's license documentation states an offline license lets routers "start and serve traffic without a persistent connection to GraphOS," where "an offline router gets its supergraph schema from a local supergraph schema file" instead of Apollo Uplink — so the schema and telemetry can stay in-country. Apollo notes this is "available on an as-needed basis to Enterprise organizations." | Apollo — GraphOS Router License (offline license), retrieved 2026-10-13 |
| Sending a China-origin GraphQL schema and per-operation telemetry to a US control plane is a cross-border transfer (数据出境) under PIPL Articles 38–40 — requiring Article 13/23 notice, a separate consent, and a transfer mechanism (a CAC security assessment, the CAC standard contract, or certification) — wherever that schema or telemetry carries personal information. | PIPL Articles 13, 23, 38–40 — 21YunBox gov-doc summary |
| For a critical information infrastructure operator or high-volume handler, the Cybersecurity Law's Article 39 (formerly Article 37) requires personal information generated in mainland China to be stored in-country — which a US-only GraphOS control plane cannot satisfy, but a self-hosted, offline in-country Apollo Router can. | Cybersecurity Law Article 39 (formerly Article 37) — 21YunBox gov-doc summary |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a team running Apollo GraphQL into a mainland-China product, the first thing to settle is that the question is not whether GraphOS Studio paints quickly from Shanghai, or whether an engineer can open the schema explorer. Apollo splits into two very different things. The Apollo Router is a runtime you can self-host in your own infrastructure — it sits in front of your subgraphs and executes operations. GraphOS — the schema registry, the usage-metrics and insights suite, and the Studio web interface — is a SaaS control plane. The compliance exposure is not the runtime loading; it is what the control plane receives when you use it. By Apollo’s own data-privacy documentation, GraphOS ingests your registered GraphQL schema and, from the router, “the normalized query operation string for every executed operation” along with per-resolver timing — and Apollo “processes and stores data in the United States.” That schema shape and per-operation telemetry expose your API surface and, through field-level usage, the patterns of the user data your graph serves. Sending it to an offshore control plane is a data-residency and cross-border-transfer question — settled by where the registry and telemetry live, not by a page-load test.
Apollo GraphQL in China at a glance
| What decides it | In Apollo's own terms — and China's law |
|---|---|
| Two halves: a self-hostable runtime, a SaaS control plane | The Apollo Router runs in your own infrastructure. GraphOS — the schema registry, usage-metrics/insights suite and Studio — is a hosted control plane. The residency question is not whether the router runs; it is what GraphOS receives and stores when you use it. |
| What GraphOS receives — schema + per-operation telemetry | By Apollo's own documentation GraphOS ingests “Schema registration via schema reporting” and, from the router, “The normalized query operation string for every executed operation” plus per-resolver timing. Your “operation results never even reach any Apollo-managed service” — but the schema shape and operation telemetry do, exposing your API surface and field-level usage patterns. |
| US-only control plane — the distinctive second half | The half a reachability check never sees. In Apollo's own words, “Apollo processes and stores data in the United States,” and “all data processing and storage occurs in the United States.” No region is in mainland China. So using GraphOS routes your schema and per-operation telemetry to a control plane offshore — the transfer happens on registration and on every reported operation, not when someone opens a dashboard. |
| The self-hosted router is the residency lever | Apollo's license documentation states an offline license lets routers “start and serve traffic without a persistent connection to GraphOS,” where “an offline router gets its supergraph schema from a local supergraph schema file” instead of Apollo Uplink. Run the router in-country, feed it a local schema, and the schema and telemetry stay resident — Apollo notes offline licensing is “available on an as-needed basis to Enterprise organizations.” |
| Residency & cross-border | Where the schema and operation telemetry carry personal information, sending them to a US control plane is a cross-border transfer (数据出境) under PIPL Articles 38–40 — notice, a separate consent, and a transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). For a critical information infrastructure operator or high-volume handler, Cybersecurity Law Article 39 (formerly Article 37) wants China-collected personal information stored in the mainland — which a US-only GraphOS cannot satisfy but an in-country router can. |
| Reachability is not the axis | Whether Studio or the router answers from the mainland is operational, not the compliance question. What decides it is where the registry and telemetry live. 21YunBox helps you run the router in-country, keep the schema and telemetry resident, ICP-file any China-facing GraphQL endpoint, and deliver compliantly — the 21YunBox Optimizer — in front of what you already run. Never circumvention of any kind. |
What GraphOS actually receives — your schema, and the shape of your data
Apollo GraphQL is not one monolithic service, and the distinction is the whole compliance story. The Apollo Router is a runtime: you deploy it, it sits in front of your subgraphs, and it executes incoming operations. You can run it on infrastructure you control, and that is where the credentials and connection details for your own subgraphs live. GraphOS is the opposite — a managed control plane that your tools talk to. You publish your schema into its registry, the router reports operations to it, and you read the results in the Studio web interface and its insights suite.
What travels to that control plane is specific, and Apollo documents it plainly. GraphOS ingests “Schema registration via schema reporting,” so your composed GraphQL schema — the full map of your types, fields and relationships — is held by Apollo. From the router it ingests, in Apollo’s words, “The normalized query operation string for every executed operation” and “Trace data indicating the execution time for every resolver in the operation.” Apollo is careful that your payloads stay out: “Your graph’s operation results never even reach any Apollo-managed service,” and by default the router sends neither GraphQL variable values nor HTTP header values. But the two things that do go — the schema and the per-operation telemetry — are not nothing. The schema is your API surface; the normalized operations plus field-level timing are a running record of which fields are used, how often, and together — the usage shape of the very user data your graph serves. And all of it, by Apollo’s own statement, is “processed and stored in the United States.”
The doors: residency, cross-border, sensitive PI and ICP
Point your graph at GraphOS and the first door opens. Where the schema and the per-operation telemetry describe or derive from the personal information of users in China, holding them on a control plane in the United States is a cross-border transfer (数据出境). The duty lands on you, the handler, not on Apollo: 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 generated in China to be stored in the mainland, with a security assessment before any export. A GraphOS control plane with no mainland-China region structurally cannot meet that duty; a self-hosted, in-country router can.
A quieter door is sensitivity. Where the fields your operations touch carry government IDs, financial 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 — a risk to confirm against what your graph actually exposes. And a third door follows from publishing: the moment you expose a public, China-facing GraphQL endpoint — an app’s API, a customer portal’s data layer — 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 open GraphOS Studio, watch the router return a query, and conclude “it works.” That answer is beside the point. The compliance exposure is not on the screen — it is in what the control plane receives and where it comes to rest: your registered schema and, on every executed operation, the normalized operation string and resolver timing, held in the United States. A page-load test measures none of that. It cannot see that your schema is registered offshore, that per-operation telemetry is reported across the border, whether separate consent was taken, or that a China-facing GraphQL endpoint needs an ICP filing.
There is a second trap specific to a platform of this shape. Making GraphOS merely reachable from the mainland — or even running the router inside China while it still publishes to and reports to the US control plane — does not keep the regulated data in-country, because the schema and the operation telemetry have still crossed the border. The reverse is also true and is the lever: Apollo’s own offline-license path lets the router run disconnected, drawing its supergraph from a local schema file rather than Apollo Uplink, so the schema and telemetry never leave. What decides residency is where the registry and telemetry live — not whether a screen draws or a router can connect. That is the competitor-proof second half of the question, and it is why keeping the schema and telemetry in-country, not merely making GraphOS reachable, is the answer.
The lawful path — map, localize, deliver
There is a compliant way to run Apollo GraphQL for a mainland-China team, and because the Apollo Router is self-hostable it sits on the stack you already use — no rebuild, no migration off Apollo.
First, map: our China compliance team inventories what GraphOS holds and sends for your graph — which schemas are registered, what per-operation telemetry and resolver timing the router reports, whether any of it describes personal or sensitive personal information — and establishes where the router runs today, where the registry and metrics live (the US control plane), and the consent and transfer basis each flow relies on. We build the technical picture; the legal conclusions are settled with counsel.
Then localize: run the self-hosted Apollo Router on in-country infrastructure — keeping the credentials to your subgraphs and the operation telemetry on the mainland — and, where the schema and usage data must stay resident, use Apollo’s offline-license path so the router draws its supergraph from a local schema file instead of the offshore control plane. Obtain the Article 13/23 notice and separate consent, treat any government IDs or financial data as sensitive personal information, and use a lawful cross-border mechanism (a CAC security assessment, the standard contract, or certification) only where a transfer is genuinely needed. Localize means keeping in-country what the law says must stay — never a route that ships the schema or telemetry offshore anyway, and never any form of circumvention.
Then deliver: any public, China-facing GraphQL endpoint in front of your graph — an app’s API, a customer portal’s data layer — 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 (or in place of) the offshore control plane, 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 Apollo GraphQL stack you already run, not a competitor to it.
None of this is a verdict that Apollo GraphQL 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 schema and operations actually expose — worth settling the specifics with counsel before your China graph’s schema and telemetry start crossing the border on every operation.
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
