Does PyPI Work in China? Data Residency, ICP & Cross-Border Rules
Your private Python packages are proprietary code that often embeds credentials and API tokens, and PyPI (pypi.org) does not host them — so they sit on an offshore private registry while your China build's dependency supply chain runs cross-border. A compliance-first look at the residency and supply-chain exposure and the in-country self-hosted private-index lever.
Does PyPI work in China?
The question that decides PyPI in China is not whether pip install reaches the index — it is where your private packages, and the secrets baked into them, are allowed to live. PyPI (pypi.org, the Python Software Foundation's public index) does not host private packages, so your proprietary code sits on an offshore private registry while your China build's dependency supply chain runs cross-border: a residency and supply-chain problem, not a performance one.
Your private distributions are internal SDKs, client libraries and build logic — proprietary source code, i.e. trade secrets — and they routinely embed credentials, API tokens and config, sometimes test-fixture personal data. Because PyPI "does not support publishing private packages," that concentrated code and its secrets live on a hosted private registry (often an offshore vendor cloud) or a server you run, and pip resolves builds from "https://pypi.org/simple" by default. Where a package embeds Chinese users' personal data, keeping it offshore is a cross-border transfer under PIPL (Articles 38–40), with an in-mainland storage duty for CIIOs and large-volume handlers (Cybersecurity Law Article 39, formerly Article 37). The lawful lever is to keep private packages, artifacts and secrets in-country on a self-hosted private index — not to make the public endpoint reachable; the ICP filing lands on the app in front of the stack.
This is a risk map, not a verdict — which transfer mechanism fits, and whether a localization duty applies, turns on your entity, your data volumes and whose data it is. Our China team can map your exposure →
What PyPI's own documentation says about China
| Fact | Primary source |
|---|---|
| PyPI is the public index and does not host private packages — so your proprietary code lives elsewhere. Asked "How can I publish my private packages to PyPI?", PyPI's Help page answers: "PyPI does not support publishing private packages." The index is maintained "by the Python Software Foundation and Python community, for the Python community" and served from outside mainland China. For a private package, PyPI's own recommended path is to "run your own deployment of the devpi project," and for availability to "consider either a mirror or a private index" — so your private packages sit on a hosted private registry (often offshore) or a server you run. | PyPI — Help (Python Software Foundation), pypi.org, retrieved 2026-10-13 |
| Your China build's dependency supply chain resolves offshore by default — and can be pointed at your own in-country index. pip's documented default index is the "Base URL of the Python Package Index (default https://pypi.org/simple)," an offshore endpoint, and private packages come from indexes added with "--extra-index-url." The Python Packaging User Guide confirms the self-host path: "If you wish to host your own simple repository … you can either use a software package like devpi." So what code enters your mainland deployment, and from where, is governable — a self-hosted in-country index keeps the supply chain resident. | pip documentation — pip install (pip.pypa.io); Python Packaging User Guide — Hosting your own index (packaging.python.org), retrieved 2026-10-13 |
| Where a private package embeds Chinese users' personal data, storing it offshore is a cross-border transfer under PIPL. Private distributions and test fixtures can carry personal data; populating or hosting such a package on an offshore registry triggers PIPL Articles 38–40 — the handler (you, not PyPI) must give notice, obtain a separate consent and satisfy one transfer mechanism (a CAC security assessment, the standard contract, or certification). See the Personal Information Protection Law and cross-border data transfers under PIPL. | PIPL Articles 38–40; China cross-border data transfer rules, retrieved 2026-10-13 |
| For some handlers the data must stay in China — and an offshore private registry has nowhere in-country to keep it. A critical information infrastructure operator, or a handler above the regulators' volume thresholds, must store China-collected personal data in the mainland (PIPL Article 40; Cybersecurity Law Article 39, formerly Article 37; the 2025 amendment in force January 1, 2026 renumbered 37 to 39, substance unchanged). The in-country remedy is a self-hosted private index on mainland infrastructure, keeping private packages, artifacts and secrets resident. | 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 China-facing engineering team, the deciding question about PyPI is not whether pip install can reach the index from Shanghai — it is where your private packages, and the secrets baked into them, are allowed to live. The Python Package Index at pypi.org is the public, community index operated by the Python Software Foundation, and it is where open-source dependencies are shared. Your own packages are a different thing entirely: an internal SDK, a shared client library, build and deployment logic, feature modules — proprietary source code, and therefore trade secrets. Those private distributions routinely embed credentials, API tokens, connection strings and config, and sometimes carry test-fixture personal data. Three prongs decide the answer: that your private packages are proprietary code plus embedded secrets; where that concentrated code and those secrets physically rest; and your China build’s dependency supply chain — what code enters your mainland deployment, and from where. Reachability of the public index is not the axis.
PyPI in China at a glance
| What decides it | In PyPI's own terms — and China's law |
|---|---|
| What your private packages are | Not community dependencies — your own internal SDKs, client libraries, build logic and feature modules. That is proprietary source code: trade secrets, concentrated in one place. |
| What they carry | Private distributions routinely embed credentials, API tokens, connection strings and config, and sometimes test-fixture personal data. A build artifact is rarely just code. |
| Where they live | PyPI "does not support publishing private packages," so your private packages sit elsewhere — a hosted private registry or feed (often an offshore vendor cloud), or a server you run. PyPI's own recommended path is to "run your own deployment of the devpi project." |
| Your China build's supply chain | pip resolves from "https://pypi.org/simple" by default — offshore — and you add private indexes with --extra-index-url. What code enters your mainland deployment, and its provenance and integrity, is a cross-border supply-chain question. |
| The law | Where a private package embeds Chinese users' personal data, or your processing involves personal data, offshore storage is a cross-border transfer (PIPL Articles 38–40), with an in-mainland storage duty for CIIOs and large-volume handlers (PIPL Article 40; Cybersecurity Law Article 39, formerly Article 37). |
| Reachability is not the axis | Making the public index merely reachable or mirrored does not move your private packages or their secrets in-country. The lawful lever is a self-hosted in-country private index; the ICP filing lands on the app in front of the stack, not on the index. |
What a private Python package actually is — proprietary code, with secrets inside
A dependency you pull from pypi.org is someone else’s open-source code. The packages your own team publishes are the opposite: an internal SDK, a shared data-access library, your build and release tooling, product modules you never intend to open-source. That is proprietary source code, and the law treats concentrated, non-public source as a trade secret. Worse for residency, a private distribution is rarely pure logic. Teams bundle configuration, service clients with baked-in API tokens, connection strings and credentials, and test fixtures that can contain real personal data. So a private package index is not a convenience cache — it is a concentrated store of your intellectual property and your secrets. Where that store physically rests is a data-residency decision, and PyPI, by design, is not where it rests.
Where your private packages live — and why PyPI isn’t it
PyPI is the public index, and it says so in its own words. Its Help page answers the question “How can I publish my private packages to PyPI?” with a single flat sentence: “PyPI does not support publishing private packages.” The index at pypi.org exists to share open-source distributions with the community; it is maintained, in the Foundation’s own footer, “by the Python Software Foundation and Python community, for the Python community,” and served globally from outside mainland China. Because your private packages cannot live there, they live somewhere else — and that “somewhere” is the exposure. Most teams land on a hosted private registry or feed, which means your proprietary code and its embedded secrets sit on a vendor’s offshore cloud: a data-residency and trade-secret concentration abroad. PyPI’s own guidance points the other way — for a private package, “the recommended solution is to run your own deployment of the devpi project,” and for availability it tells you to “consider either a mirror or a private index.” A reachability check never sees any of this. It asks whether the endpoint responds; it cannot see that your proprietary code and secrets are parked offshore.
Your China build’s dependency supply chain crosses the border
The second half most teams miss is provenance. A pip install is a supply chain: your mainland build resolves and pulls distributions, and whatever it pulls becomes part of what you deploy in China. pip’s own default makes the shape clear — the index is the “Base URL of the Python Package Index (default https://pypi.org/simple),” an offshore endpoint, and private packages come from indexes you add with --extra-index-url. When both the public and the private index sit abroad, every build reaches across the border for the exact code — and the exact secrets — that will run in your China deployment, with integrity and provenance you now have to reason about across a cross-border link. The compliance question is not “can the build resolve packages fast” but “what code enters my China deployment, from where, and where do my private packages and secrets rest while it does.”
Why a reachability check misses all of this
Benchmarks and “is it up from China” checks answer a different question than the one that decides compliance. An endpoint can respond quickly and your posture can still be wrong, because speed and availability say nothing about residency. A registry mirror or cache improves availability of public packages — a legitimate supply-chain measure — but it does not move your private packages or their embedded secrets in-country, and it does not change where your proprietary code rests. The axis here is residency and supply chain: whether your private distributions, build artifacts, credentials and any embedded personal data stay in the mainland, and whether the code entering your China build comes from an in-country source you govern. Those are exactly the things a reachability test cannot see — and exactly what a self-hosted in-country private index addresses.
This is a risk map, not a verdict: whether a localization duty applies, and which cross-border mechanism fits, turns on your entity, how much personal data you hold and whose it is — settle the specifics with counsel before you build.
The lawful path — map, localize, deliver
PyPI stays your public source of open-source dependencies; nothing is rebuilt or migrated. What 21YunBox adds is the compliance and delivery layer around your private packages and build.
- Map. We inventory which of your packages are private — your proprietary code — whether they embed credentials, tokens or personal data, where that private registry is hosted today, and how your China build’s dependency supply chain resolves.
- Localize. We help you keep private packages, build artifacts and their secrets resident by running a self-hosted private index in-country (for example a self-managed devpi, Nexus or Artifactory on mainland infrastructure), point your China build at it, and minimize what crosses the border — so proprietary code and embedded secrets stay in the mainland. Keeping it in-country means exactly that; 21YunBox never uses or suggests circumvention of any kind.
- Deliver. The application built on those packages carries an ICP filing duty and needs compliant, in-country delivery — the 21YunBox Optimizer, in front of the stack you already run, with no rebuild.
21YunBox is a compliant overlay and partner, not a competitor to PyPI or to any package-registry tooling. The goal is simple: your Python build and the private packages behind it run legally and compliantly for your team in China, with your proprietary code and secrets where the law wants them.
Related reading:
- China’s Personal Information Protection Law (PIPL)
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law — data localization (Article 39, formerly Article 37)
- How to get an ICP filing for China
