Does Retool Work in China? Data Residency, ICP & Cross-Border Rules
Retool connects into your databases and APIs and holds those connection secrets, so compliance turns on where the instance runs — not on whether the editor loads. Retool Cloud is hosted offshore (US region us-west-2, no mainland-China region), making your China data a PIPL cross-border transfer — while a self-hosted edition you run on your own infrastructure keeps the internal-tool data and the secrets resident in-country.
Does Retool work in China?
Retool loading from Shanghai was never the compliance question. Retool’s whole job is to connect into your databases and APIs — and to hold the credentials for them — so building and running internal apps on your China users’ and employees’ data through an offshore instance ships that data, and concentrates your secrets, across the border before latency ever enters the picture.
Retool Cloud runs in Retool’s primary US region (AWS us-west-2, Oregon), with no mainland-China region, so an app built there stores your internal-tool data and holds your connection secrets offshore — a cross-border transfer PIPL governs (notice, separate consent and a transfer mechanism), and for a critical information infrastructure operator or large-volume handler, China-collected personal information must stay in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). The lever is that Retool also ships a self-hosted edition whose instances “run on your own infrastructure,” so you deploy it in-country and keep both the data and the secrets resident.
This is a risk map, not a verdict — your exposure turns on what the tools touch, your role and whose data they process. Our China team can map it with you →
What Retool's own documentation says about China
| Fact | Primary source |
|---|---|
| Retool ships a self-hosted edition that runs on infrastructure you control. Retool’s own documentation states that “Self-hosted instances run on your own infrastructure,” and lets you “Choose between a Retool-managed or self-managed” self-hosted instance, deployed on a Kubernetes cluster using Helm. Because the instance — and the internal-tool data and connection configuration it holds — runs where you deploy it, you can run it on mainland-China infrastructure. That is the residency lever: the offshore Retool Cloud is not the only path. | Retool — Self-hosted deployments (docs.retool.com), retrieved 2026-10-13 |
| Retool Cloud is hosted offshore, and it is the layer that holds your connection secrets. Retool’s docs state that on Cloud, “By default, traffic routes through the us-west-2 region, based in Oregon, US,” and “Queries run through Retool’s primary region in us-west-2 regardless of the outbound region you have set” — the only other regions named are Frankfurt and Singapore, and we found no mainland-China region. Retool connects into your own databases and APIs and stores those connection configurations, so an offshore instance keeps your internal-tool data and your database credentials, API keys and OAuth tokens outside the mainland. | Retool — Configure Retool outbound regions for cloud instances (docs.retool.com), retrieved 2026-10-13 |
| Running Retool offshore moves your China data across the border. Because an offshore instance stores your internal-tool data and reaches into your China systems to render apps and run queries, processing a mainland user’s or employee’s personal information through it is a cross-border transfer under PIPL (数据出境) — it requires notice and a separate consent (Articles 13 and 23) and one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (Articles 38–40). The handler is you, not Retool. | PIPL Articles 13, 23 and 38–40, retrieved 2026-10-13 |
| A CIIO or large-volume handler owes an in-country storage duty an offshore Retool Cloud cannot meet. For a critical information infrastructure operator — and, at the volumes the Cyberspace Administration of China specifies, a large-volume handler — personal information collected in the mainland must be stored in the mainland under PIPL Article 40 and the Cybersecurity Law Article 39 (formerly Article 37); the 2025 amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39 (substance unchanged). An offshore Retool Cloud region structurally cannot satisfy it; a self-hosted, in-country instance can. | PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37), retrieved 2026-10-13 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a product or an internal operation that touches mainland China, the first question about Retool is not whether the app editor loads or whether your team can reach it from Shanghai — it can. The question is where the instance, the data it holds, and the credentials it carries are allowed to come to rest. Retool is an internal-tools builder: it connects directly into your own databases and APIs and builds apps on top of them, which means it stores your internal-tool definitions and the data those apps read and write, keeps the accounts of the employees who use them, and — crucially — holds the connection secrets for the systems it reaches: database credentials, API keys, and OAuth tokens. Where all of that physically sits is the compliance question, and it is set by where you run Retool, not by how fast the editor paints.
Two facts fix the posture. Retool Cloud — the hosted path — runs in Retool’s own primary region in the United States (AWS us-west-2, Oregon), with no mainland-China region, so an app built there keeps your internal-tool data and your connection secrets offshore. But Retool also ships a self-hosted edition whose instances, in Retool’s own words, “run on your own infrastructure” — and that is the residency lever: deploy it on mainland-China infrastructure and the data and the secrets stay in-country. This page is a compliance-risk map for that choice, not a speed test.
Retool in China at a glance
| What decides it | In Retool's own terms — and China's law |
|---|---|
| Where the instance and its data physically rest | Retool Cloud is Retool's hosted service, and its primary region is AWS us-west-2 in Oregon, US — "Queries run through Retool's primary region in us-west-2 regardless of the outbound region you have set." The only other regions Retool names for Cloud are Frankfurt and Singapore; we found no mainland-China region. The self-hosted edition is different: its "instances run on your own infrastructure," so you choose where it — and the data and secrets it holds — comes to rest, including on mainland-China soil. |
| What Retool holds — and why it's personal information | Retool builds internal apps on top of your systems, so an instance holds your internal-tool definitions, the data those apps read and write, and the accounts of the employees who use them — names, emails, identifiers, and the records your tools surface about your China users. Tied to identifiable people, that is personal information under the Personal Information Protection Law, and sensitive personal information under PIPL Article 28 where financial, health, precise-location, or minors' data appear. |
| The platform is itself the cross-border pipe | Retool's whole function is to connect into your own databases and APIs and hold the credentials for them — database passwords, API keys, OAuth tokens. Run the instance offshore and its normal operation pulls your China systems' data across the border to render apps and run queries, while concentrating your secrets outside the mainland. That is a cross-border transfer under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. |
| The in-country storage duty | For a critical information infrastructure operator — and, at the volumes the Cyberspace Administration of China specifies, a large-volume handler — personal information collected in the mainland must be stored in the mainland under PIPL Article 40 and the Cybersecurity Law Article 39 (formerly Article 37); the 2025 amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39 (substance unchanged). An offshore Retool Cloud region structurally cannot meet it. |
| Reachability isn't the axis — the lawful path | That the editor opens quickly from Shanghai changes nothing: the data and the secrets still rest wherever the instance runs, and the residency duty still applies. Because Retool ships a self-hostable edition, the lawful path is to run it in-country — self-hosted on mainland infrastructure — and to put any China-facing surface in front of it on ICP-filed delivery. |
Where you run Retool decides it
Retool’s compliance posture is set by where you deploy it, not by a load-time test. Retool’s own documentation describes two hosted shapes. Retool Cloud is the fully hosted path, and its traffic and queries run through Retool’s primary US region: “By default, traffic routes through the us-west-2 region, based in Oregon, US,” and “Queries run through Retool’s primary region in us-west-2 regardless of the outbound region you have set.” The outbound regions you can add are Frankfurt and Singapore — Retool notes they “do not affect where Retool stores your applications or data” — and none is in mainland China.
The self-hosted edition is the lever. Retool states plainly that “Self-hosted instances run on your own infrastructure,” letting you “Choose between a Retool-managed or self-managed” deployment, run on a Kubernetes cluster using Helm. The same software runs identically whether it sits in Oregon or on mainland-China infrastructure, so residency is a question of where you deploy it, not of whether the software works — which is why this page publishes no first-party China latency figure for Retool: speed is not the axis for data and secrets sitting in the wrong country. See our explainer on cross-border data transfers under PIPL.
What Retool holds — your data and your secrets
Retool is not a page sitting in front of your data — it is wired into it. To build an internal app you connect Retool to your databases and APIs as “resources,” and Retool stores those connection configurations so your apps can query them. That makes a Retool instance two sensitive things at once: a store of your internal-tool data and the employee accounts that use it, and a concentration of the credentials — database passwords, API keys, OAuth tokens — that unlock your own systems.
For a China-facing operation, the data those tools surface about mainland users, and about the employees who operate them, is personal information under the Personal Information Protection Law wherever it relates to an identified or identifiable person, and sensitive personal information under PIPL Article 28 where financial, health, precise-location, or minors’ data appear. Keep the instance offshore and both halves live abroad: the records in a place China’s law treats as outside the country they were collected in, and the keys to your systems alongside them. This is the half a reachability check never sees — and the distinctive one for an internal-tools platform, because the platform’s normal operation is the cross-border movement of your China systems’ data.
Why a reachability check misses the real question
A browser in Shanghai can open an offshore Retool editor and the apps built on it, so a reachability or latency test will report “works.” But reachability is the delivery half, not the legal half. The violation a connection test can never see is structural: the instance is hosted offshore, so your internal-tool data and your connection secrets are stored abroad, and every app that reads from a China system runs that read across the border. An offshore instance can hold neither an in-country copy of the data a localization duty demands, nor the ICP-filed footing a public mainland surface needs (State Council Order No. 292; MIIT Order No. 33). Making the offshore instance merely reachable does not answer the question; running it in-country does.
This is a risk map, not a verdict: whether you owe a transfer mechanism, in-country storage, or both depends on the data your tools touch, your volumes, and whose it is — worth settling with counsel before you build.
The lawful path — map, localize, deliver
You keep Retool as your internal-tools platform. What 21YunBox adds is the compliance layer it was never meant to provide on its own, arranged around the stack you already run — no rebuild, no second codebase, no migration off Retool. 21YunBox is a compliant overlay and a partner to Retool, not a competitor.
- Map. Our China team inventories what your Retool apps hold and reach — the internal-tool data, the employee and end-user records, the China systems they connect to, and the credentials the instance stores — and reads your PIPL cross-border, data-residency (CII) and ICP obligations against your entity, your data volumes, and whose personal information is in play.
- Localize. Where the law requires your China data to stay on the mainland, we help you run Retool in-country — the self-hosted edition on mainland infrastructure — so the internal-tool data and the connection secrets stay resident. Localize means a lawful in-country deployment, never a route back to an offshore endpoint.
- Deliver. Every China-facing surface in front of Retool — the apps, the API edge, the portals your mainland users and staff reach — runs over ICP-filed, in-country delivery (the 21YunBox Optimizer), in front of the stack you already have.
The result runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind.
Related reading:
- China’s Personal Information Protection Law (PIPL)
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
