Does Spring Boot Work in China? Data Residency, ICP & Cross-Border Rules
Spring Boot is open-source Java you run on your own servers, so it is residency-neutral and runs fine in China. The real question is where you deploy it and where its database lives — a mainland-facing host owes an ICP filing and MLPS, and the China personal data it stores is governed by PIPL and cross-border rules.
Does Spring Boot work in China?
Whether you can use Spring Boot in China is a deployment-and-data question, not a speed one. Spring Boot is open-source Java you compile into your own application and run on your own servers — it runs fine inside the mainland, so the risk is legal, not performance.
By Spring's own project page, Spring Boot makes it easy to create "stand-alone, production-grade Spring based Applications" you can just run. There is no hosted Spring Boot service and no China region to select — the framework is residency-neutral. What is not neutral is where you put the app and its database: an app serving mainland users from an offshore host owes an ICP filing and MLPS duties it may not have, and every record of a China user written to an offshore database is a cross-border transfer of personal information PIPL governs — notice, separate consent, a transfer mechanism, and for a CIIO or large-volume handler, in-country storage. Its Maven / Gradle dependencies resolve offshore on every build, too.
This is a risk picture, not a verdict — your obligations turn on where you deploy, your data volumes, and your role. Our China team can map your Spring Boot deployment and data exposure with you →
What Spring Boot's own documentation says about China
| Fact | Primary source |
|---|---|
| In Spring's own words: Spring Boot "makes it easy to create stand-alone, production-grade Spring based Applications that you can 'just run'." It is open-source code you compile into your own application artifact and run on servers you choose — there is no hosted Spring Boot service and no region to select, so where the app and its database sit is your deployment decision, not a property of the framework. | Spring — Spring Boot project page, retrieved 2026-10-14 |
| Spring Boot is developed in the open and distributed under the Apache License 2.0, and its build declares dependencies that resolve from Maven Central and the Gradle plugin portal — repositories operated outside the mainland. So the framework self-hosts in-country without restriction, while its build-time supply chain routes across the border on every clean build; both the running app and its pipeline are deployment choices you control. | Spring Boot source repository (Apache-2.0); Maven Central, retrieved 2026-10-14 |
| Because a Spring Boot app's database holds the accounts, profiles and records it collects from users in China — personal information — storing that database offshore while serving the mainland is a cross-border transfer. PIPL governs it: the handler (you, the operator of the app — not Spring and not your hosting vendor) must give notice, obtain separate consent, and satisfy one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification (Articles 38–40). | Personal Information Protection Law, Articles 38–40 and Article 28, retrieved 2026-10-14 |
| For a CIIO or large-volume handler, personal information and important data collected in-country must be stored inside mainland China, with a security assessment before any export (Cybersecurity Law Article 39 (formerly Article 37); renumbered by the 2025 amendment in force January 1, 2026, substance unchanged). Separately, any mainland-facing deployment owes an ICP filing (备案) and MLPS (等级保护) obligations as the system operator. | Cybersecurity Law, Article 39 (formerly Article 37), retrieved 2026-10-14 |
Sources verified by the 21YunBox compliance team on 2026-10-14.
For a mainland-China audience, the first thing to settle about Spring Boot is that the question is not whether it runs, and not really about Spring Boot at all. Spring Boot is an open-source Java framework — you add it to your own codebase, compile it into a self-contained application, and run that application on whatever servers you choose. By itself it is residency-neutral: it holds no data of its own and runs identically in a Beijing data centre or a Frankfurt one. What holds the data is the application you build with it — and, above all, the database that application reads from and writes to. So “does Spring Boot work in China” resolves into three different questions: where does the app run, where do its database and the personal information it collects come to rest, and where do its build-time dependencies resolve from? Those are deployment and data questions, and they — not the framework — decide your compliance posture.
Spring Boot in China at a glance
| What decides it | In Spring Boot's own terms — and China's law |
|---|---|
| Where it actually runs | Spring Boot is open-source Java you compile into your own application and run wherever you deploy it. There is no hosted "Spring Boot" service and no region to select, so the framework itself is residency-neutral. What is not neutral is the host you deploy to: an app that serves mainland users from an offshore server is the real exposure, and a mainland-facing deployment owes an ICP filing (备案) and carries MLPS (等级保护) obligations as the system operator. |
| Where the personal data lives | The data is in your app's database, not in the framework. The accounts, profiles, orders and records a Spring Boot app collects from users in China are personal information; if that database sits offshore, the data has been taken abroad. Where government IDs, financial, health, or biometric data appear, PIPL Article 28 adds heightened duties for sensitive personal information. |
| Data crossing the border | When an app serving mainland users writes their records to a database hosted outside China, 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. For a CIIO or large-volume handler, China personal information must be stored in-country (Cybersecurity Law Article 39 (formerly Article 37)). |
| Where its dependencies resolve | A Spring Boot build resolves its libraries from Maven Central (and Gradle's plugin portal), which are operated offshore, so your CI pulls those artifacts across the border on every build. That is a supply-chain and residency concern that rides along with the framework — separate from where the running app and its data sit, and invisible to a check that only asks whether the site loads. |
| Reachability is not the axis | There is no Spring Boot server to ping, so this is not a block and speed is not the deciding factor. The decision turns on residency — where the app is deployed, where its database and the China personal information it holds come to rest, and on what legal basis. This page publishes no first-party latency figure; speed is the wrong axis. |
The framework runs where you run it — so the deployment decides residency
Start with where Spring Boot runs, because the whole question rests on it. Spring Boot is a framework you add to your own project: its project page describes it as making it easy to create “stand-alone, production-grade Spring based Applications that you can ‘just run’,” and the project ships as open-source code under the Apache License 2.0. The build produces a self-contained artifact you deploy on servers you choose — there is no hosted Spring Boot to connect to and no in-country region to pick. In that sense Spring Boot is reachable and usable from China in a way a blocked consumer service is not, and it can run entirely in-country.
What that also means is that Spring Boot never sets your residency posture — your deployment does. Put the same application on an offshore virtual machine that mainland users hit, and you have created the exposure: an app serving the mainland public from a host with no ICP filing (备案), running as a system operator that owes MLPS (等级保护) obligations it has not met. Put it on infrastructure inside the mainland, filed and graded, and that same code is on lawful ground. The framework is identical either way. So the compliance question is not answered by looking at Spring Boot. It is answered by looking at where you deployed it, and what that host is allowed to serve.
The data lives in your database, not the framework
A Spring Boot application is where your users’ data comes to rest, and the framework is only the plumbing around it. Through Spring Data and your persistence layer, the app reads and writes a database — and that database holds the accounts, profiles, transactions and records your product collects from users in China. That is personal information, and the moment a mainland user’s record is written to a database hosted outside China, it has crossed the border. China’s Personal Information Protection Law puts the duty on the handler — you, not the framework and not the hosting vendor: Articles 38–40 require notice, a separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification), and Article 28 adds heightened duties where the records are sensitive — government IDs, financial, health, biometric, or minors’ data that a real application so often stores.
And if any of that data is “important data,” or your organization operates critical information infrastructure, the Cybersecurity Law adds a data-localization duty — Article 39 (formerly Article 37; renumbered by the 2025 amendment in force January 1, 2026, substance unchanged) requires personal information and important data collected and generated in-country by such operators to be stored in-country, with a security assessment before any export. None of this is a property of Spring Boot. All of it is a property of the database you wired it to and the users you serve.
Build-time dependencies resolve offshore
The running app is one thing; the pipeline that builds it is another, and it is worth being plain about it. A Spring Boot project declares its libraries in Maven or Gradle, and those dependencies resolve from Maven Central and the Gradle plugin portal — repositories operated outside the mainland. Every clean build, and every CI run, pulls those artifacts across the border. That is not a personal-information transfer in the PIPL sense, but it is a supply-chain and residency concern that rides along with the framework: a build that silently depends on reaching an offshore registry is fragile from inside China, and the provenance of what you ship is decided abroad. The lever here is to resolve dependencies from an in-country artifact repository your build controls, so the supply chain for your China deployment comes to rest on mainland soil rather than depending on a border crossing on every build.
Why a reachability check misses this
A reachability or latency test pings an endpoint and reports whether it answers and how fast. For Spring Boot that test answers the wrong question twice over. First, there is no Spring Boot endpoint to ping — the framework compiles into your own application, so a green light on your site tells you nothing about where your database and its China user records actually sit. Second, what decides compliance is invisible to a probe: which host the app runs on and whether it carries an ICP filing, whether the database holding mainland users’ personal information sits offshore, whether that data is sensitive or “important,” and whether your build quietly depends on an offshore registry. Those are deployment, data and legal facts, not network facts. That is the half a pure speed-or-reachability view cannot supply — and the half we lead with.
The lawful path — map, localize, deliver
For an open-source framework, 21YunBox’s role is focused, and we will say so plainly: there is no “domestic Spring Boot” to sell you — the framework is already yours to run, including in-country. Our value is in three moves.
First, we map the exposure: where the app is actually deployed and whether that host carries an ICP filing and meets its MLPS obligations; where the database sits and what personal, sensitive, or “important” data it collects from China users; how that lands against PIPL’s cross-border rules, Article 28, and the Cybersecurity Law’s localization duty; and where your build resolves its dependencies — so you and your counsel can set the guardrails. Second, we help you localize what cannot lawfully stay offshore: stand up the app and the database that must remain resident on ICP-filed, MLPS-appropriate infrastructure inside the mainland, with an in-country artifact repository for the build, so China user data comes to rest on Chinese soil. This is a China-legal footing, never a route around the rules. Third, we deliver the China-facing surface your users hit — the app or API edge your mainland users reach — over ICP-filed, in-country infrastructure (the 21YunBox Optimizer), in front of the Spring Boot app you already run, with no rebuild and no second codebase.
21YunBox is a compliant overlay, not a migration, and a partner to the tools you use, not a competitor to them. 21YunBox never uses or suggests circumvention of any kind. The result is a setup that runs legally and compliantly for your users in China.
Related reading:
- How to get an ICP filing for China
- Cross-border data transfers under PIPL
- China’s Personal Information Protection Law
- China’s Cybersecurity Law (data localization, Article 39)
