Does BrowserStack Work in China? Data Residency, ICP & Cross-Border Rules
On BrowserStack your app build, test scripts, production-like fixtures and each run's screenshots, videos and logs live in its offshore data centers — no mainland-China region, not self-hosted. For China users that is PIPL cross-border plus residency exposure; a self-hosted in-country grid is the lever.
Does BrowserStack work in China?
Whether you can use BrowserStack in mainland China is first a data-residency question, not a question of whether the test can reach it. BrowserStack is a hosted real-device and browser cloud: when you run a test, your application build, your test scripts, your production-like fixtures and the screenshots, videos and logs of each run execute on and are stored in BrowserStack's own data centers.
By BrowserStack's own documentation those data centers sit in the United States, Europe, India, Australia and the United Kingdom — there is no mainland-China region, and BrowserStack is not a product you self-host. So for your users in China, the app build you upload and the production-like fixtures and run recordings it generates are held offshore the moment a test runs: a cross-border transfer of personal information that PIPL governs, and for a CIIO or large-volume handler, data the Cybersecurity Law requires be stored in the mainland. Whether the service is reachable from Shanghai is the least of what you are deciding.
This is a risk picture, not a verdict — your obligations turn on your data volumes and your role. Our China team can map your BrowserStack exposure with you →
What BrowserStack's own documentation says about China
| Fact | Primary source |
|---|---|
| In BrowserStack's own documentation: its Geo Region Restriction control states that “BrowserStack provisions test devices from data centers in the restricted region,” and lists the regions it supports as “United States (us),” “Europe (eu),” “India (aps),” “Australia (apse)” and “United Kingdom (uk)” — none in mainland China. Even BrowserStack's own data-residency control cannot keep your test data on Chinese soil. | BrowserStack — App Automate Geo Region Restriction, retrieved 2026-10-13 |
| BrowserStack describes itself as a cloud of real devices it hosts: “Devices you access are all real devices housed in our data centers.” Its residency doc confirms that “Your uploaded applications (.apk, .aab, .ipa), test suites, and other media files are stored and processed” within a region, and that “All logs and data generated from your test runs are stored within the region,” including “text logs, visual logs, video logs, network logs, Appium logs, device logs.” Your app build and run recordings live wherever that region is — and none is in mainland China. | BrowserStack — App Automate overview and Geo Region Restriction, retrieved 2026-10-13 |
| Personal information collected from people in China and sent abroad is a cross-border transfer under the Personal Information Protection Law. The handler must give notice, obtain separate consent, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification (PIPL Articles 38–40). Production-like test fixtures and run recordings that contain personal data fall within this the moment they leave the country on an offshore test run. | PIPL Articles 38–40 — 21YunBox gov-doc reference, retrieved 2026-10-13 |
| For a critical information infrastructure operator or large-volume handler, personal information and important data collected in China must be stored inside the mainland under the Cybersecurity Law Article 39 (formerly Article 37). A hosted test cloud with no mainland-China region cannot meet that duty; keeping the test execution and its artifacts in-country can — and standing that up legally is what brings an ICP filing into scope. | Cybersecurity Law Article 39 (formerly Article 37) — 21YunBox gov-doc reference, retrieved 2026-10-13 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
Ask whether BrowserStack “works” in mainland China and the honest answer starts with where your testing lives, not with whether a session opens from Shanghai. BrowserStack is a hosted real-device and browser cloud: when you run a test, your application build — your own proprietary front-end and back-end code — is uploaded to BrowserStack, your test scripts execute there, your test fixtures (routinely production-like: real-looking names, emails and payment fields, sometimes copies of real records) are fed in, and BrowserStack produces artifacts — screenshots and video recordings of your app rendering that data, plus console, network and device logs. All of it runs on and is stored in BrowserStack’s own data centers. By BrowserStack’s own documentation those data centers are in the United States, Europe, India, Australia and the United Kingdom — there is no mainland-China region, and BrowserStack is not a product you self-host. Whether the session is reachable is real, but it is the least of what you are deciding.
BrowserStack in China at a glance
| What decides it | In BrowserStack's own terms |
|---|---|
| Where it runs | Tests run on real devices and browsers BrowserStack hosts: “Devices you access are all real devices housed in our data centers.” Its Geo Region Restriction control lists the regions it supports as the United States, Europe, India, Australia and the United Kingdom — no region is in mainland China. |
| What executes there | Your application build, your test scripts and your test fixtures. In BrowserStack's words, “Your uploaded applications (.apk, .aab, .ipa), test suites, and other media files are stored and processed” within the chosen region — so your proprietary code and your fixtures run offshore. |
| The run recordings | Every run produces artifacts. In BrowserStack's words, “All logs and data generated from your test runs are stored within the region,” including “text logs, visual logs, video logs, network logs, Appium logs, device logs.” These capture your app rendering your data. |
| Where that data sits | Offshore. Because the chosen region is the US, EU, India, Australia or the UK, any personal data your fixtures or recordings capture from users in China is transferred abroad — a cross-border transfer PIPL governs, with a localization duty an offshore-only cloud cannot meet. |
| A self-hosted option? | No. BrowserStack is a hosted cloud, not a product you run on your own infrastructure, and it publishes no mainland-China region — so there is no first-party in-country residency path. Confirm current options with BrowserStack before relying on one. |
| Is it reachable? | Whether a BrowserStack session opens cleanly from mainland China is a delivery question — separate from, and lesser than, whether you are cleared to run your app build and hold these recordings offshore at all. |
Where BrowserStack runs — and that settles the first question
BrowserStack is hosted software, and its own documentation names where the work happens. App Automate’s overview states plainly that “Devices you access are all real devices housed in our data centers.” Its data-residency control — Geo Region Restriction — lets an enterprise pin data to one geography, and the regions it supports are “United States (us),” “Europe (eu),” “India (aps),” “Australia (apse)” and “United Kingdom (uk)”. There is no mainland-China region. So wherever your team sits, the app build you upload, the scripts you run and the recordings BrowserStack keeps for you are held offshore. That single fact decides the compliance question before reachability is ever measured: this is not about whether a session opens in Shanghai, but about your proprietary code and your users’ data leaving the country the moment a test runs.
Prong one — your app build and your China users’ data in the fixtures leave the country
A test run exercises your application build — your proprietary front-end and back-end code — and feeds in test fixtures that are routinely production-like: real-looking names, emails and payment fields, sometimes copies of real records. BrowserStack keeps the uploaded artifacts in the chosen region: in its own words, “Your uploaded applications (.apk, .aab, .ipa), test suites, and other media files are stored and processed” within that region. When those fixtures carry the personal information of people in China, moving them to a US, EU, Indian, Australian or UK data center is a cross-border transfer the Personal Information Protection Law governs: you must give notice, obtain separate consent, and clear one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification (PIPL Articles 38–40). If you are a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland under the Cybersecurity Law Article 39 (formerly Article 37) — a residency duty an offshore-only test cloud cannot satisfy. This is application and user data, not “can the session stream,” and it is the spine of the question.
Prong two — the recordings of each run are offshore too, and that is the half a reachability check never reaches
Every BrowserStack run produces artifacts: screenshots and video recordings of your application rendering your data, plus console, network and device logs. In BrowserStack’s own words, “All logs and data generated from your test runs are stored within the region,” and that includes “text logs, visual logs, video logs, network logs, Appium logs, device logs.” A video of your checkout flow filled with production-like records is personal data at rest in an offshore data center; so is a network log of your API responses. A probe that only confirms the session opens never sees where those recordings live — it cannot see your app build sitting in a data center in the US, the EU, India, Australia or the UK, and it cannot see the video of your app rendering real-looking records stored beside it. That is the second half of the question, and it is the part a connectivity check structurally cannot answer. Keeping the recordings — and the execution that produces them — in-country is the only thing that does.
Why a reachability check misses this
A test that only asks “can my suite reach BrowserStack from Shanghai?” — or whether the tool can fetch its browser binaries — measures the wrong thing. It never sees that your application build was uploaded to a data center in the US, the EU, India, Australia or the UK; it never sees that your production-like fixtures and the video of your app rendering them are stored in that same offshore region; and it never sees the notice-consent-and-mechanism duties PIPL attaches to that data once it leaves China. Making the offshore cloud merely reachable does not move the regulated data or the recordings in-country, and it does not create the transfer basis the law requires. Reaching the service and being cleared to run your app and hold its recordings offshore are two different tests — and only one of them shows up on a latency chart.
The lever: map, localize, deliver
- Map — inventory which test runs carry your proprietary application build, which fixtures hold production-like or real personal data, and where the execution and the screenshots, videos and logs end up; separate the hosted offshore runs from anything you already run yourself.
- Localize — run the browser and device grid and the test execution inside mainland China, on a self-hosted grid or self-hosted runners you own — an open-source Selenium or Appium grid, or your own in-country CI — so the app build, the test data and the run artifacts stay resident; send offshore only what is lawful to export.
- Deliver — 21YunBox stands up the compliant in-country test grid in front of (or in place of) the offshore cloud, with no rebuild of your tests.
Standing that in-country execution up legally — on infrastructure inside the mainland — is also what brings an ICP filing into scope, and it is exactly the footing an offshore test cloud cannot give you.
Keep your tests — move the execution in-country
You do not have to abandon BrowserStack-style testing or rewrite your suites to be compliant. The fix is to change where the test executes: 21YunBox stands up a compliant, self-hosted in-country browser and device grid — an open-source Selenium or Appium grid, or self-hosted runners, that you own and that sit inside the mainland — so your application build, your production-like fixtures and the screenshots, videos and logs of each run stay resident, and only what is lawful to export ever leaves. We map which runs carry proprietary code and which fixtures hold personal data, localize the execution, and deliver the in-country footing in front of your existing pipeline — no rebuild. Tell us your stack and we’ll scope the in-country path and a quote with you.
