Does LaunchDarkly Work in China? PIPL Cross-Border, Automated Decisions & Data Residency
LaunchDarkly is reachable from mainland China, but its flag and experiment decisions run offshore: the user context you send to target a flag, and the evaluation and analytics events sent back, are personal information processed on US or EU servers with no mainland-China region. A compliance-first look at the PIPL cross-border transfer and Article 24 automated-decision exposure.
Does LaunchDarkly work in China?
LaunchDarkly loads fine from China — but the user context you send it to target a flag or experiment is evaluated on its US or EU servers to decide what each person sees, and that is where the compliance exposure sits.
To evaluate a flag you pass LaunchDarkly a context — a user key, often an email, plan, device, IP and custom traits — and impressions and analytics events stream back; there is no mainland-China region. On China users that is both a PIPL cross-border transfer of personal information and an Article 24 automated decision about what each user sees. The lawful lever is to keep the flag-evaluation and user data in-country — a self-run in-cluster evaluation component or a licensed domestic alternative, the least identifying context, and the Article 24 opt-out — not to make the offshore SDK reachable.
Which duty bites first depends on what context you send and who your users are — a map to settle before you build. Our China team can map your exposure →
What LaunchDarkly's own documentation says about China
| Fact | Primary source |
|---|---|
| The SDK evaluates flags locally, yet LaunchDarkly still receives the evaluation data — and you can run an in-cluster evaluation component yourself. LaunchDarkly's architecture documentation states a server-side SDK "stores and evaluates this initial feature flag data in an in-memory cache," but "the SDK sends information about flag evaluations back to LaunchDarkly" (client-side and mobile SDKs call its evaluation endpoint directly). The same docs describe optional components you install and run yourself, where "you control the data that flows in or out of them" — the basis for keeping evaluation in-country. | LaunchDarkly — Architecture (launchdarkly.com/docs), retrieved 2026-10-10 |
| LaunchDarkly processes data in the US or EU — no mainland-China region. Its EU instance resides in "the AWS Frankfurt (eu-central-1) region" beside the default US instance and a separate US federal instance, and its List of Subprocessors, effective December 18, 2025, names processing locations in the USA, Germany, France, Ireland and Singapore. None is in mainland China, so your China users' context and events are evaluated and stored offshore. | LaunchDarkly — List of Subprocessors, effective December 18, 2025, retrieved 2026-10-10 |
| Sending targeting context offshore is a PIPL cross-border transfer, and the flag decision is automated decision-making. As the handler you owe notice, a separate consent and a transfer mechanism under PIPL Articles 38–40, and a flag or experiment that chooses what each user sees from their attributes is automated decision-making under PIPL Article 24 — which requires a way to refuse and, for profiling, an option not to be targeted by personal characteristics. | Personal Information Protection Law (PIPL), Articles 24 and 38–40 |
| A CIIO or high-volume handler also carries an in-country storage duty. Where it applies, personal information must be stored in the mainland under PIPL Article 40 and Cybersecurity Law Article 39 (formerly Article 37) — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged. No US or EU region can satisfy it. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37); PIPL Article 40 |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a mainland-China audience, the question about LaunchDarkly is not whether its SDK or streaming service can be reached — it is what happens to the user context you send it. To target a flag or run an experiment, you hand LaunchDarkly a context: a user key, and often an email, a plan or tier, a device, geography, IP, and whatever custom attributes you choose. Server-side SDKs evaluate flag rules locally in an in-memory store, but “the SDK sends information about flag evaluations back to LaunchDarkly,” and client-side and mobile apps call its evaluation endpoint directly — so the targeting context, and the impression and analytics events it returns, flow to LaunchDarkly’s servers, which run in the United States or, by option, the European Union, with no mainland-China region. That turns on three questions at once: a PIPL cross-border transfer of personal information, an Article 24 automated decision about what each user sees, and consent for the behavioral tracking behind it.
LaunchDarkly in China at a glance
| What decides it | In LaunchDarkly's own terms — and China's law |
|---|---|
| What you send | To evaluate a flag or experiment you pass LaunchDarkly a context — a user key, and often an email, plan, device, geography, IP and custom attributes. Those identifiers and traits are personal information, and the impression and analytics events stream back as well. |
| Where it is evaluated and stored | LaunchDarkly runs in the United States, with an optional EU instance in “the AWS Frankfurt (eu-central-1) region” and a separate US federal instance — no mainland-China region. Sending your China users' context there is a PIPL cross-border transfer (Articles 38–40, 数据出境). |
| It decides what each user sees | A flag or experiment chooses which variation each context receives from its attributes — automated decision-making under PIPL Article 24, which requires transparency and fairness, a way to refuse, and, for profiling-based decisions, an option not to be targeted by personal characteristics. |
| Consent and residency | Non-essential experimentation and behavioral tracking need the user's consent (PIPL Articles 13 and 23), not a buried notice. A critical information infrastructure operator or high-volume handler also carries an in-country storage duty (Cybersecurity Law Article 39, formerly Article 37). |
| Reachability is not the axis | Reaching the SDK or streaming service is not the question. The lawful path keeps flag-evaluation and user data in-country — a self-run in-cluster component or a licensed domestic alternative, the least identifying context, and the Article 24 opt-out — while the app that consumes the decisions carries an ICP filing for in-country delivery. |
What you actually send — your users’ attributes and behavior
LaunchDarkly is a feature-management and experimentation platform: you wrap features in flags, roll them out, target them, and test variants against each other. To do that, your application evaluates a flag against a context — in LaunchDarkly’s model, the user or entity you are serving, carrying “any attributes you specify.” In practice that means a user key, and commonly an email, a plan or tier, a device and app version, geography, IP, and custom traits you attach for targeting. Those are personal information the moment the user is a real person in China.
How that context reaches LaunchDarkly depends on the SDK. A server-side SDK, in LaunchDarkly’s words, “stores and evaluates this initial feature flag data in an in-memory cache,” so raw context can stay inside your process — but “the SDK sends information about flag evaluations back to LaunchDarkly,” which is how impressions, experiment exposures and analytics are recorded. Client-side and mobile SDKs go further, sending the context to LaunchDarkly’s evaluation endpoint to fetch each user’s variations. Either way, identifiers and behavior tied to your China users leave the country for LaunchDarkly’s US or EU servers — there is no mainland-China region to keep them in, and an experiment or personalized rollout steadily adds to the record of who saw what.
It’s a cross-border transfer — and an automated decision — under PIPL
Sending your China users’ context and events to LaunchDarkly’s offshore servers is, in PIPL’s terms, a cross-border transfer of personal information (数据出境). As the handler — you, not LaunchDarkly — you owe the Article 38–40 duties before the first context leaves: give notice, obtain a separate consent for the transfer, and clear one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). The mechanics are set out in our note on cross-border data transfers under PIPL.
The distinctive prong is Article 24. A feature flag or an experiment is, almost by definition, automated decision-making: it decides which variation, which feature, which experience each user receives from their attributes or cohort. PIPL Article 24 governs exactly that — it requires the decision to be transparent and fair, gives the individual a way to refuse, and, where the decision or push is based on profiling, requires an option not to be targeted by their personal characteristics. Running an experiment on a China segment, or personalizing from a profile, is profiling you have to be able to switch off for the individual who asks.
Consent is a third duty: non-essential experimentation and the behavioral events behind it need the user’s informed consent under PIPL Articles 13 and 23 — a buried “by using this product…” line does not carry it. And where you are a critical information infrastructure operator or a high-volume handler, a data-localization duty attaches: the personal information must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37) — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged), a residency no US or EU region can satisfy.
Reaching the SDK isn’t the question — keeping the decisioning in-country is
None of this is a latency problem, so none of it is solved by making the offshore endpoint faster or more reachable. The exposure is that the decision, and the data behind it, sit offshore; the lawful answer is to bring both onto an in-country path.
LaunchDarkly gives you a real lever here. It offers an optional in-cluster flag-delivery and evaluation component you run inside your own infrastructure: in its own words, “you install and configure the components, and you control the data that flows in or out of them.” Hosted inside China, that component lets your SDKs evaluate against a local cache, so raw context need not traverse the border for every evaluation. Be precise about what it is, though — it is a cache and relay, not a full on-premises replacement: the flag configuration still originates from LaunchDarkly’s managed service, and experiment and analytics events are still designed to flow back. So the in-cluster component is one tool, paired with minimizing and pseudonymizing the context you do send (evaluate with the least identifying key, ideally no raw email or IP), honoring the Article 24 right to a non-profiled option, and — where residency or volume demands it — routing China users through a licensed in-country experimentation alternative instead. Keeping the decisioning on an in-country path is the goal; shipping the same data offshore under another name is not.
This is a risk map, not a verdict. Whether the cross-border rules, the Article 24 duties, a consent gap, or a data-localization obligation bite first depends on what context you send, what you experiment on, and who your users are — worth settling the specifics with counsel before you build.
The lawful path — map, localize, deliver
You keep running LaunchDarkly. 21YunBox adds the piece its offshore service cannot, as a compliant overlay in front of the stack you already run — no rebuild, no migration.
- Map — we inventory the context and events your flags and experiments send: what attributes they carry, where each is evaluated and stored, how they decide what users see, whether a persistent profile accumulates offshore, and the consent basis you rely on.
- Localize — we keep China-user flag-evaluation and data on an in-country path: the self-run in-cluster component hosted inside China where it fits, or a licensed domestic experimentation alternative where residency or volume demands it; the least identifying context sent offshore; and the Article 24 opt-out honored. 21YunBox never uses or suggests circumvention of any kind.
- Deliver — the app or site that runs your flags and consumes the decisions carries an ICP filing duty and needs compliant, in-country delivery — the 21YunBox Optimizer, placed in front of your existing origin, so a mainland audience is served lawfully without moving off your global stack.
The result is LaunchDarkly that runs legally and compliantly for your users in China, with the decisioning and the personal information behind it on an in-country footing.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- China’s data export security assessment measures
- How to get an ICP filing for China
