Does Ably Work in China? PIPL Cross-Border, Delivery & Data Residency
Ably is a London-based realtime platform — pub/sub, WebSockets, presence and channels. Every connection, presence record and live message from your China users crosses the border to its offshore edge (no mainland-China region): a PIPL cross-border transfer. And Ably push rides FCM, unavailable in mainland China. A compliance-first look at the exposure and the lawful in-country path.
Does Ably work in China?
Using Ably in China isn't about whether the SDK connects — it's that the connection, presence and live message data you push through it crosses the border to Ably's offshore edge, a transfer you answer for under PIPL.
Every realtime session hands Ably the client identifiers you assign your users, presence data about who is online, and the message payloads themselves — personal information processed and persisted at seven core routing datacenters (Singapore, Ireland, Frankfurt, the United States, Sydney), none in mainland China, with residency pinnable only to the EU or US. That makes it a PIPL cross-border transfer you, the handler, must give notice for, take separate consent for, and cover with a transfer mechanism. If you also use Ably push, Android delivery rides Firebase Cloud Messaging, which is unavailable in mainland China, so reaching Chinese Android devices lawfully means routing through licensed in-country manufacturer channels. The lever is to keep delivery and recipient data in-country on a licensed path and govern the transfer — not to make the offshore SDK reachable.
This is a risk map, not a verdict — your duties turn on your role and data volumes. Our China team can map your Ably exposure →
What Ably's own documentation says about China
| Fact | Primary source |
|---|---|
| Ably has no mainland-China region. Its own Global edge network page describes "7 geographically-distributed core routing datacenters and 635 edge acceleration points-of-presence" built primarily on Amazon EC2; the seven core routing datacenters — where connections, channels, presence and persisted messages are handled — are in Singapore, Ireland, Frankfurt, the United States and Sydney, none in mainland China, and Ably's enterprise docs let an account pin data only to the EU or the US. So the identifiers, presence and messages from your China users are processed and stored offshore. | Ably — Global edge network (and enterprise data residency docs), retrieved 2026-10-10 |
| Ably push reaches phones through FCM and APNs only — not a Chinese manufacturer channel. Its push docs state a device "registers with FCM or APNs" and name FCM (Android), APNs (iOS) and Web Push as the transports; none of Xiaomi, Huawei/HMS, OPPO or vivo appears. Firebase Cloud Messaging depends on Google Play Services, which is unavailable on most mainland-China Android devices, so FCM-dependent Android push does not reliably arrive there — lawful reach means routing Android push through licensed in-country manufacturer channels. APNs works for iOS, but the token and content still cross the border. | Ably Docs — Configure and activate devices, retrieved 2026-10-10 |
| Sending China users' realtime data offshore is a cross-border transfer PIPL puts on you. Under PIPL Articles 38–40, the personal-information handler — you, the Ably customer, not Ably — must give notice, obtain a separate consent distinct from the user's agreement to use the service, and satisfy one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification. Marketing or promotional push adds the Article 13/23 lawful-basis-and-consent and opt-out duty. | PIPL Chapter III, Articles 38–43 |
| A CIIO or high-volume handler must keep that data inside mainland China. The data-localization duty of the Cybersecurity Law Article 39 (formerly Article 37) requires personal information collected in the mainland to be stored there; Ably offers no mainland-China region, so meeting it means an in-country delivery and data path rather than an offshore edge. Whether it applies turns on your role and data volumes — a question for counsel. | Cybersecurity Law of the People's Republic of China, Article 39 (formerly Article 37) |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a mainland-China audience, the question about Ably is not whether its SDK can open a connection from inside the country. It is what travels across that connection. Ably is a London-based realtime platform — pub/sub, channels, presence and message history — and every realtime session carries personal information: the connection and client identifiers you assign your users, presence data about who is online and what they are doing, and the live message payloads themselves — a chat line, a location update, a collaborative edit. Ably handles and persists that at its offshore edge — seven core routing datacenters in Singapore, Ireland, Frankfurt, the United States and Sydney, none in mainland China — so sending it there is a cross-border transfer of personal information under PIPL (Articles 38–40). If you also use Ably push, Android delivery rides Firebase Cloud Messaging, which is unavailable in mainland China: a second, China-specific delivery door. Marketing push adds a consent duty; raw realtime transport does not by itself trigger Article 24 profiling; and a CIIO or high-volume handler faces an in-country storage duty.
Ably in China at a glance
| What decides it | In Ably's own terms — and China's law |
|---|---|
| What it is | Ably is a London-based realtime platform — pub/sub, WebSockets, channels, presence and message history, plus a push-notifications feature. It is operated from outside the mainland: its network runs on seven core routing datacenters (Singapore, Ireland, Frankfurt, three in the United States, and Sydney), built primarily on Amazon EC2, and there is no mainland-China region or cluster where your realtime data is handled or stored. |
| What you hand it | The connection and client identifiers you assign your users, presence data (who is online and their state), and the live message payloads themselves — and, if you use Ably push, the device token plus the notification content. All of it is personal information. Carried to Ably's offshore edge, that is a cross-border transfer under PIPL (Articles 38–40, 数据出境): notice, a separate consent, and one transfer mechanism. |
| The delivery door (Android push) | Ably push reaches phones through FCM (Android) and APNs (iOS); its docs name FCM, APNs and Web Push as the transports and no Chinese manufacturer channel. Firebase Cloud Messaging depends on Google Play Services, which is unavailable on most mainland-China Android devices, so FCM-dependent Android push does not reliably arrive — lawful reach means routing Android push through the device manufacturers' own in-country push services (Xiaomi, Huawei/HMS, OPPO, vivo). APNs works for iOS, but the token and content still cross the border. |
| Consent, profiling & residency | Promotional or marketing push needs the Article 13/23 lawful basis, consent and a working opt-out. Raw pub/sub transport does not by itself make automated decisions about your users, so Article 24 profiling generally attaches to your own targeting logic, not to Ably's pipe. Ably can pin account data only to the EU or the US; where you are a CII operator or high-volume handler, mainland personal information must be stored in the mainland — the data-localization duty of the 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). |
| The lawful path | Reachability and speed are not the axis. Route China-user realtime and push through a lawful in-country path — licensed manufacturer channels for Android push, an in-country realtime delivery path for connections and payloads — minimize and pseudonymize the data sent offshore, obtain marketing consent, keep a lawful cross-border basis, and ICP-file and deliver the app in-country. 21YunBox maps that path, localizes the China leg, and delivers the app with the Optimizer in front of the stack you already run. |
What you actually send — connection identifiers, presence and message payloads
A realtime connection is never just a socket. Every channel your China users join carries that person’s connection and client identifiers (the clientId you assign them), their presence data — the signal that says they are online and what state they are in — and the live message payloads themselves: a chat line, a cursor position, a score update, a collaborative edit. All of it is personal information, and with Ably it is processed and persisted outside the mainland. Ably’s own network page describes a global edge of “7 geographically-distributed core routing datacenters and 635 edge acceleration points-of-presence,” built primarily on Amazon EC2; the seven core routing datacenters — where connections terminate and channels, presence and message history are handled — are in Singapore, Ireland, Frankfurt, the United States and Sydney. Ably does list mainland-China cities among its edge acceleration points-of-presence, but those are acceleration nodes, not core routing datacenters: the connection, the presence set and any persisted message history still resolve to one of the offshore core datacenters, and Ably’s enterprise documentation lets you pin account data only to the EU or the US — never mainland China. If you also use Ably push, the device token and the notification content are added to what leaves the country. Ably acts as your processor; the handler that carries the China-law duty is you.
It’s a cross-border transfer — and Android delivery has its own door — under PIPL
Put those facts together and the picture is a regulatory one, on two legs. The first is data. Collecting a mainland user’s connection identifiers, presence and message content and carrying them to a service operated offshore is a cross-border transfer of personal information under China’s Personal Information Protection Law (数据出境). PIPL puts the duty on the handler — you, the operator of the app, not only the vendor — and Articles 38–40 require notice, a separate consent distinct from the user’s agreement to use the service, and one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification. If any of the messaging is commercial — a promotional push, a re-engagement notification — Articles 13 and 23 add a lawful-basis-and-consent requirement and a working opt-out. Because Ably is transport rather than a targeting engine, Article 24 automated-decision-making generally attaches to your own logic about who receives what, not to the realtime pipe itself — but if you layer profiling on top, that duty is yours to meet. Where you are a critical information infrastructure operator or handle personal information above the state threshold, storage localizes in the mainland — the data-localization duty of the Cybersecurity Law Article 39 (formerly Article 37).
The second leg is delivery, and for Android push it is its own door before it is anything else. Ably delivers push to phones through Google’s Firebase Cloud Messaging on Android and Apple’s APNs on iOS — its documentation states that a device “registers with FCM or APNs” and names FCM, APNs and Web Push as the transports. But FCM relies on Google Play Services, which is not available on most mainland-China Android devices, and Google operates no mainland-China region; a push that depends on FCM therefore does not reliably reach Chinese Android users. Reaching them lawfully and reliably means routing through each device manufacturer’s own in-country push service — Xiaomi, Huawei (HMS), OPPO, vivo and the rest — each of which requires a registered app and credentials with that vendor, and increasingly a filed, content-compliant app. Ably’s push documentation names no such Chinese manufacturer channel, so that routing is something you add around it. APNs does work for iOS because Apple operates in China through a local entity, but the device token and the notification content you send still cross the border. This is a lawful in-country delivery-channel requirement, not a performance problem.
Reaching the SDK isn’t the question — lawful in-country delivery is
So the useful question is not “can Ably open a WebSocket to Shanghai today?” It is whether your China-bound realtime and push ride a lawful channel and have a lawful basis to leave the country at all. For Android push that means routing through the licensed in-country manufacturer channels that actually deliver to Chinese handsets; for realtime it means an in-country path for the connections, presence and payloads rather than resolving every China session to an offshore core datacenter. On top of either, it means minimizing and pseudonymizing the identifiers and content you send, obtaining the Article 13/23 consent for anything promotional and honoring opt-out, and keeping a lawful cross-border basis for whatever still leaves. This is a localization of the China leg onto a lawful, in-country path — it is emphatically not a tunnel that ships the users’ data offshore anyway. Whether and how each of these rules applies to your exact use case, volumes, and entity is a risk to settle with qualified counsel against what you actually ship.
The lawful path — map, localize, deliver
There is a lawful way to reach your users in China with realtime features and notifications, and it has three moves. Map: inventory which channels, presence and push flows serve China users, what identifiers and content each one carries, where Ably processes and stores it (its offshore core datacenters, EU/US residency only) and what it persists — message history, presence, connection metadata — the consent basis for anything promotional, and how your Android push is actually being delivered today (FCM that silently fails versus licensed manufacturer channels). Localize / govern: keep China-user delivery and data on an in-country path — route Chinese Android push through the licensed manufacturer channels, run realtime through an in-country delivery path, and keep APNs tokens and content governed — minimize and pseudonymize what is sent offshore, obtain the consent marketing requires and honor opt-out, and hold a lawful cross-border basis for anything that still leaves. Deliver: the app or site that opens the connections and triggers the notifications is a public internet service with an ICP filing duty, and it needs compliant, in-country delivery — the 21YunBox Optimizer — in front of the stack you already run, with no rebuild or migration. The result is a realtime and notification flow that runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law — data localization (Article 39, formerly Article 37)
- China’s Data Export Security Assessment Measures
- How to get an ICP filing for China
