Does Appwrite Work in China? Data Residency, ICP & Cross-Border Rules
Appwrite Cloud is reachable from China, but the real question is data residency, not speed: every project's database, auth records, storage and API secrets sit in one offshore region — none in mainland China — so Chinese users' data is stored abroad under PIPL. Plus the open-source self-host lever.
Does Appwrite work in China?
Whether you can use Appwrite in China is a data-residency question, not a speed one.
Appwrite Cloud stores every project's database, auth records and storage in one region you pick, and by Appwrite's own list those regions are Frankfurt, New York, San Francisco, Singapore, Sydney and Toronto — none in mainland China. So the personal data your app collects from users in China lands offshore: a cross-border transfer PIPL governs, needing notice, separate consent and a transfer mechanism. The backend also concentrates your auth records, database rows and API secrets abroad.
The lever is that Appwrite is open source: "Appwrite was designed from the ground up with self-hosting in mind," so you can run it on infrastructure inside the mainland and keep the regulated data — and the secrets — resident. That in-country path, ICP-filed, is the compliant one. Our China team can map your Appwrite exposure with you →
What Appwrite's own documentation says about China
| Fact | Primary source |
|---|---|
| In Appwrite's own words, "Appwrite is currently available in the following list of regions" — Frankfurt, New York, San Francisco, Singapore, Sydney and Toronto, with Bangalore, Amsterdam and London marked coming soon. None is in mainland China. Each project's database, auth and storage sit in the one region you choose, so the data an Appwrite Cloud app collects from users in China is stored offshore. | Appwrite Docs — Regions, retrieved 2026-10-13 |
| Appwrite is open source and self-hostable. Its docs state "Appwrite was designed from the ground up with self-hosting in mind" and present self-hosting as giving "full control over data location." You run the same engine — database, auth, storage and functions — on your own infrastructure, which is what lets the regulated data and the API secrets stay inside mainland China. | Appwrite Docs — Self-hosting, retrieved 2026-10-13 |
| Storing personal information collected from users in China in an offshore Appwrite Cloud region is a cross-border transfer under PIPL (Articles 38–40). The handler — you, the Appwrite customer, not Appwrite — must give Article 13/23 notice, obtain separate consent, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification. | PIPL Articles 38–40 — notice, separate consent, transfer mechanism |
| For a critical information infrastructure operator or a high-volume handler, personal information collected in China must be stored inside the mainland (Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40). No Appwrite Cloud region meets that — self-hosting the open-source edition in-country can, and an ICP filing makes a China-facing deployment lawful. | Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a mainland-China audience, the deciding question about Appwrite is not whether it loads — Appwrite Cloud is reachable — but where the data it holds is allowed to live. Appwrite is a backend-as-a-service: it keeps the accounts, auth sessions, database rows, uploaded files and the server-side functions your application runs on. By Appwrite’s own documentation, Appwrite Cloud deploys each project into one region you choose, and that region list is Frankfurt, New York, San Francisco, Singapore, Sydney and Toronto — not one of them in mainland China. So a China-facing app on Appwrite Cloud is reachable, yet every record of user data it stores lands offshore: a cross-border transfer China’s data law governs, not a performance problem. Reaching it is not the problem; where it keeps your users’ data — and your secrets — is.
Appwrite in China at a glance
| What decides it | In Appwrite's own terms |
|---|---|
| Where your data lives | Appwrite Cloud deploys each project into one region — Frankfurt, New York, San Francisco, Singapore, Sydney or Toronto — and its database, auth and storage all sit in that region. None of the available regions is in mainland China. |
| Your secrets and the backend itself | The same platform holds your project's API keys, database credentials and auth tokens, and runs every read and write your app makes. On Appwrite Cloud those secrets and that processing sit on offshore infrastructure. |
| The cross-border transfer | Personal information your app collects from users in China is written to that offshore region — a cross-border transfer PIPL governs, and the handler is you, the Appwrite customer, not Appwrite. |
| When the rules bite harder | For a CIIO or a high-volume handler, personal information collected in China must be stored inside the mainland (Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40) — a duty no Appwrite Cloud region can meet. |
| The in-country lever | Appwrite is open source and self-hostable — "designed from the ground up with self-hosting in mind" — so you can run the same engine on mainland infrastructure and keep the data and secrets resident, standing it up lawfully with an ICP filing. |
| Is it reachable? | Even where Appwrite Cloud loads from China, that settles nothing. Reachability is not the compliance question — where the data and secrets live is. |
Where your Appwrite data actually lives
Appwrite is a managed backend — database, authentication, file storage and server-side functions — and on Appwrite Cloud all of it sits together in a single region. In its own Regions documentation, “Appwrite is currently available in the following list of regions”, and that list is Frankfurt, New York, San Francisco, Singapore, Sydney and Toronto, with Bangalore, Amsterdam and London marked coming soon. The region you pick is where the project’s services and data are hosted, and the same docs tell you to “ensure the region aligns with legal requirements for data residency and sovereignty specific to your application’s domain.”
The catch for China is the menu you get to choose from: not one of those regions is inside mainland China. So the moment your application serves users in China, the accounts, profiles, database rows and files it writes are kept abroad — and that, not latency, is what China’s data law responds to.
It is not only the data — your secrets and the backend sit offshore too
A reachability check asks one thing: can I open the app from Shanghai. It never sees the second exposure. Appwrite is where your application’s API keys, database credentials and auth tokens live, and the backend’s whole job is to read and write your users’ data on every request. Run that backend on Appwrite Cloud and two things are offshore at once: the regulated personal information your China users generate, and the concentration of secrets and processing that sit on top of it. Because the backend itself runs abroad, each login, query and upload from a user in China crosses the border by design — the platform’s normal operation is the cross-border transfer, not an occasional export. Keeping the data resident but leaving the secrets and the engine offshore solves only half of it; only running the engine in-country keeps both.
Serve China from Appwrite Cloud and your users’ data crosses the border
Personal information your app gathers from people in China — names, emails, login identities, anything that identifies them — is written to that one offshore region. Under China’s Personal Information Protection Law, storing it outside the mainland is a cross-border transfer, and the obligation lands on the personal-information handler, which is you as the Appwrite customer and not Appwrite as the platform. PIPL asks that handler to give affected users notice, obtain their separate consent for the transfer, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification. “We already run on Appwrite” settles none of that; reaching China and being cleared to move Chinese users’ data out of it are different questions.
How much is at stake depends on your volume and your role
The weight of these duties is not uniform. Under the CAC’s cross-border rules, a handler that is not a critical information infrastructure operator and moves a smaller volume of non-sensitive personal information in a calendar year can fall under an exemption from the security assessment, the standard contract and certification — a genuinely lighter path for a small app. At the other end, a CIIO or a large-volume handler carries a data-residency duty: personal information collected in China must be stored inside the mainland (Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40). No Appwrite Cloud region can satisfy that, because none sits in China.
Here Appwrite’s own design points to the way out. Its documentation states that “Appwrite was designed from the ground up with self-hosting in mind,” lists self-hosting as giving “full control over data location,” and frames it as “ideal when you need data control or have specific compliance requirements.” The only way to keep Chinese users’ data — and your secrets — on Chinese soil is to run that self-hosted, open-source edition on infrastructure inside the mainland, and standing that deployment up lawfully is what brings an ICP filing into the picture.
Reachable, not blocked — which is why this is a data question
Whether Appwrite Cloud happens to load from a given city in China changes nothing about the real exposure. The regulated facts are that your users’ personal data is stored offshore with no mainland region to choose, and that the backend holding your secrets and running your reads and writes is offshore too. Those are compliance facts, and no amount of network tuning moves where the data and the keys sit.
This is a risk map, not a verdict: whether you owe notice and consent only, a full transfer mechanism, or in-country storage of the data itself turns on how much personal information you hold and whether your role pulls you into the CIIO or large-volume tier — a question to work through with counsel before you build.
Where 21YunBox fits — a compliant overlay, not a migration
You keep building on Appwrite; nothing moves. What we add is the layer a managed backend with no mainland region cannot give you on its own. First we map what your Appwrite deployment holds — app data, user and auth records, database rows, uploaded files, server-side functions, and the API keys and connection secrets it keeps — and which of your own systems it reaches, where it is hosted, and your consent and residency basis. Then, where the law treats your case most strictly, we help you localize: run the self-hosted, open-source Appwrite edition on infrastructure inside the mainland so the regulated data and the secrets stay resident, with Article 13/23 notice and separate consent in place and only what must cross the border crossing it — never through circumvention of any kind. Finally we deliver: compliant, ICP-filed in-country delivery standing in front of your existing origin, with the in-country backend in front of (or in place of) the offshore control plane — no re-architecture, no second codebase, your existing app left where it runs.
Related reading:
- How to get an ICP filing for China
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
