Funktioniert PyPI in China? Datenresidenz, ICP und grenzüberschreitende Regeln

Was die offizielle PyPI-Dokumentation über China sagt

Fakt	Primärquelle
PyPI ist der öffentliche Index und hostet keine privaten Pakete — Ihr proprietärer Code lebt also anderswo. Auf die Frage „How can I publish my private packages to PyPI?“ antwortet PyPIs Help-Seite: „PyPI does not support publishing private packages“. Der Index wird „by the Python Software Foundation and Python community, for the Python community“ gepflegt und von außerhalb Festlandchinas bedient. Für ein privates Paket ist PyPIs eigener empfohlener Weg, „run your own deployment of the devpi project“, und für Verfügbarkeit „consider either a mirror or a private index“ — Ihre privaten Pakete sitzen also auf einer gehosteten privaten Registry (oft im Ausland) oder einem Server, den Sie betreiben.	PyPI — Help (Python Software Foundation), pypi.org, abgerufen 2026-10-13
Die Abhängigkeits-Lieferkette Ihres China-Builds löst standardmäßig im Ausland auf — und kann auf Ihren eigenen inländischen Index gerichtet werden. pips dokumentierter Standard-Index ist die „Base URL of the Python Package Index (default https://pypi.org/simple)“, ein Offshore-Endpunkt, und private Pakete kommen von Indizes, die mit „--extra-index-url“ hinzugefügt werden. Der Python Packaging User Guide bestätigt den Self-Host-Weg: „If you wish to host your own simple repository … you can either use a software package like devpi“. Welcher Code also in Ihr Festland-Deployment eintritt, und von wo, ist regelbar — ein selbstgehosteter inländischer Index hält die Lieferkette resident.	pip documentation — pip install (pip.pypa.io); Python Packaging User Guide — Hosting your own index (packaging.python.org), abgerufen 2026-10-13
Wo ein privates Paket die personenbezogenen Daten chinesischer Nutzer einbettet, ist dessen Speicherung im Ausland ein grenzüberschreitender Transfer nach PIPL. Private Distributionen und Test-Fixtures können personenbezogene Daten tragen; ein solches Paket auf einer Offshore-Registry zu befüllen oder zu hosten, löst PIPL Art. 38–40 aus — der Verarbeiter (Sie, nicht PyPI) muss Mitteilung erteilen, eine gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen (eine CAC-Sicherheitsbewertung, den Standardvertrag oder eine Zertifizierung). Siehe das Gesetz zum Schutz personenbezogener Daten und grenzüberschreitende Datentransfers nach PIPL.	PIPL Articles 38–40; China cross-border data transfer rules, abgerufen 2026-10-13
Für manche Verarbeiter müssen die Daten in China bleiben — und eine Offshore-private-Registry hat nirgends im Inland, sie zu halten. Ein Betreiber kritischer Informationsinfrastruktur oder ein Verarbeiter oberhalb der Mengenschwellen der Regulierer muss in China erhobene personenbezogene Daten im Festland speichern (PIPL Art. 40; Cybersicherheitsgesetz Art. 39, vormals Art. 37; die Novelle 2025, in Kraft seit 1. Januar 2026, hat 37 auf 39 umnummeriert, inhaltlich unverändert). Das inländische Mittel ist ein selbstgehosteter Private-Index auf Festland-Infrastruktur, der private Pakete, Artefakte und Secrets resident hält.	PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37), abgerufen 2026-10-13

Quellen vom 21YunBox Compliance-Team am 13. Oktober 2026 geprüft.

Für ein auf China ausgerichtetes Engineering-Team ist die entscheidende Frage zu PyPI nicht, ob pip install den Index aus Shanghai erreichen kann — es ist, wo Ihre privaten Pakete und die darin eingebackenen Secrets leben dürfen. Der Python Package Index unter pypi.org ist der öffentliche, Community-Index, betrieben von der Python Software Foundation, und er ist, wo Open-Source-Abhängigkeiten geteilt werden. Ihre eigenen Pakete sind etwas völlig anderes: ein internes SDK, eine geteilte Client-Bibliothek, Build- und Deployment-Logik, Feature-Module — proprietärer Quellcode, und daher Geschäftsgeheimnisse. Diese privaten Distributionen betten regelmäßig Zugangsdaten, API-Token, Verbindungsstrings und Konfiguration ein und tragen manchmal Test-Fixture-Personendaten. Drei Zweige entscheiden die Antwort: dass Ihre privaten Pakete proprietärer Code plus eingebettete Secrets sind; wo dieser konzentrierte Code und diese Secrets physisch ruhen; und die Abhängigkeits-Lieferkette Ihres China-Builds — welcher Code in Ihr Festland-Deployment eintritt und von wo. Erreichbarkeit des öffentlichen Index ist nicht die Achse.

PyPI in China auf einen Blick

Was ein privates Python-Paket tatsächlich ist — proprietärer Code, mit Secrets darin

Eine Abhängigkeit, die Sie von pypi.org ziehen, ist der Open-Source-Code von jemand anderem. Die Pakete, die Ihr eigenes Team veröffentlicht, sind das Gegenteil: ein internes SDK, eine geteilte Datenzugriffs-Bibliothek, Ihr Build- und Release-Tooling, Produktmodule, die Sie nie als Open Source zu veröffentlichen gedenken. Das ist proprietärer Quellcode, und das Recht behandelt konzentrierten, nicht-öffentlichen Quellcode als Geschäftsgeheimnis. Schlimmer für die Residenz ist, dass eine private Distribution selten reine Logik ist. Teams bündeln Konfiguration, Service-Clients mit eingebackenen API-Token, Verbindungsstrings und Zugangsdaten und Test-Fixtures, die echte personenbezogene Daten enthalten können. Ein privater Paket-Index ist also kein Bequemlichkeits-Cache — er ist ein konzentrierter Speicher Ihres geistigen Eigentums und Ihrer Secrets. Wo dieser Speicher physisch ruht, ist eine Datenresidenzentscheidung, und PyPI ist von Bauart her nicht, wo er ruht.

Wo Ihre privaten Pakete leben — und warum PyPI es nicht ist

PyPI ist der öffentliche Index, und es sagt es in seinen eigenen Worten. Seine Help-Seite beantwortet die Frage „How can I publish my private packages to PyPI?“ mit einem einzigen flachen Satz: „PyPI does not support publishing private packages“. Der Index unter pypi.org existiert, um Open-Source-Distributionen mit der Community zu teilen; er wird, in der eigenen Fußzeile der Foundation, „by the Python Software Foundation and Python community, for the Python community“ gepflegt und global von außerhalb Festlandchinas bedient. Weil Ihre privaten Pakete dort nicht leben können, leben sie anderswo — und dieses „anderswo“ ist die Exponierung. Die meisten Teams landen bei einer gehosteten privaten Registry oder einem Feed, was bedeutet, dass Ihr proprietärer Code und seine eingebetteten Secrets auf der Offshore-Cloud eines Anbieters sitzen: eine Datenresidenz- und Geschäftsgeheimnis-Konzentration im Ausland. PyPIs eigene Leitlinie weist in die andere Richtung — für ein privates Paket ist „the recommended solution is to run your own deployment of the devpi project“, und für Verfügbarkeit sagt es Ihnen, „consider either a mirror or a private index“. Eine Erreichbarkeitsprüfung sieht nichts davon. Sie fragt, ob der Endpunkt antwortet; sie kann nicht sehen, dass Ihr proprietärer Code und Ihre Secrets im Ausland geparkt sind.

Die Abhängigkeits-Lieferkette Ihres China-Builds überquert die Grenze

Die zweite Hälfte, die die meisten Teams übersehen, ist Herkunft. Ein pip install ist eine Lieferkette: Ihr Festland-Build löst und zieht Distributionen, und was immer er zieht, wird Teil dessen, was Sie in China deployen. pips eigener Standard macht die Gestalt klar — der Index ist die „Base URL of the Python Package Index (default https://pypi.org/simple)“, ein Offshore-Endpunkt, und private Pakete kommen von Indizes, die Sie mit --extra-index-url hinzufügen. Wenn sowohl der öffentliche als auch der private Index im Ausland sitzen, greift jeder Build über die Grenze nach genau dem Code — und genau den Secrets —, der in Ihrem China-Deployment laufen wird, mit Integrität und Herkunft, über die Sie nun über eine grenzüberschreitende Verbindung hinweg nachdenken müssen. Die Compliance-Frage ist nicht „kann der Build Pakete schnell auflösen“, sondern „welcher Code tritt in mein China-Deployment ein, von wo, und wo ruhen meine privaten Pakete und Secrets, während er es tut“.

Warum eine Erreichbarkeitsprüfung all dies verfehlt

Benchmarks und „ist es aus China erreichbar“-Prüfungen beantworten eine andere Frage als die, die über Compliance entscheidet. Ein Endpunkt kann schnell antworten, und Ihre Haltung kann dennoch falsch sein, weil Geschwindigkeit und Verfügbarkeit nichts über Residenz sagen. Ein Registry-Mirror oder -Cache verbessert die Verfügbarkeit öffentlicher Pakete — eine legitime Lieferkettenmaßnahme —, aber er bewegt Ihre privaten Pakete oder ihre eingebetteten Secrets nicht ins Inland, und er ändert nicht, wo Ihr proprietärer Code ruht. Die Achse hier ist Residenz und Lieferkette: ob Ihre privaten Distributionen, Build-Artefakte, Zugangsdaten und alle eingebetteten personenbezogenen Daten im Festland bleiben und ob der Code, der in Ihren China-Build eintritt, aus einer inländischen Quelle kommt, die Sie regeln. Das sind genau die Dinge, die ein Erreichbarkeitstest nicht sehen kann — und genau, was ein selbstgehosteter inländischer Private-Index adressiert.

Dies ist eine Risikokarte, kein Urteil: Ob eine Lokalisierungspflicht gilt und welcher Grenzmechanismus passt, hängt von Ihrer Gesellschaft, wie viele personenbezogene Daten Sie halten und wessen sie sind ab — klären Sie die Einzelheiten mit Rechtsbeistand, bevor Sie bauen.

Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern

PyPI bleibt Ihre öffentliche Quelle für Open-Source-Abhängigkeiten; nichts wird neu gebaut oder migriert. Was 21YunBox hinzufügt, ist die Compliance- und Auslieferungsschicht um Ihre privaten Pakete und Ihren Build.

• Kartieren. Wir inventarisieren, welche Ihrer Pakete privat sind — Ihr proprietärer Code —, ob sie Zugangsdaten, Token oder personenbezogene Daten einbetten, wo diese private Registry heute gehostet ist und wie die Abhängigkeits-Lieferkette Ihres China-Builds auflöst.
• Lokalisieren. Wir helfen Ihnen, private Pakete, Build-Artefakte und ihre Secrets resident zu halten, indem Sie einen selbstgehosteten Private-Index im Inland betreiben (zum Beispiel ein selbst verwaltetes devpi, Nexus oder Artifactory auf Festland-Infrastruktur), Ihren China-Build darauf richten und minimieren, was die Grenze überquert — sodass proprietärer Code und eingebettete Secrets im Festland bleiben. Es im Inland zu halten, heißt genau das; 21YunBox verwendet oder empfiehlt niemals eine Umgehung welcher Art auch immer.
• Ausliefern. Die auf diesen Paketen gebaute Anwendung trägt eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung — der 21YunBox Optimizer, vor dem Stack, den Sie bereits betreiben, ohne Neuaufbau.

21YunBox ist eine rechtskonforme Overlay und Partnerin, keine Konkurrentin zu PyPI oder zu einem Paket-Registry-Tooling. Das Ziel ist einfach: Ihr Python-Build und die privaten Pakete dahinter laufen legal und rechtskonform für Ihr Team in China, mit Ihrem proprietären Code und Ihren Secrets, wo das Gesetz sie haben will.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Chinas Gesetz zum Schutz personenbezogener Daten (PIPL)
• Grenzüberschreitende Datentransfers nach PIPL
• Chinas Cybersicherheitsgesetz — Datenlokalisierung (Art. 39, vormals Art. 37)
• So erhalten Sie eine ICP-Beian für China

Häufige Fragen

Reicht es für PyPI-Compliance, pip install aus China zum Laufen zu bringen?

Nein — Erreichbarkeit ist nicht die Achse. Ob der öffentliche Index aus dem Festland antwortet, sagt nichts darüber, wo Ihre privaten Pakete, Build-Artefakte und eingebetteten Secrets ruhen oder woher der Code kommt, der in Ihren China-Build eintritt. PyPI selbst hostet keine privaten Pakete, Ihr proprietärer Code lebt also auf einer gehosteten privaten Registry (oft eine Offshore-Anbieter-Cloud) oder einem Server, den Sie betreiben. Die Compliance-Fragen sind Residenz und Lieferkette: Halten Sie Ihre privaten Pakete, Artefakte und Secrets im Inland und regeln Sie, welcher Code in Ihr Festland-Deployment eintritt. Ein selbstgehosteter inländischer Private-Index adressiert beides; ein Mirror oder Cache öffentlicher Pakete verbessert nur die Verfügbarkeit.

Wo leben unsere privaten Python-Pakete tatsächlich, und warum ist das ein Residenzproblem?

Nicht auf pypi.org. PyPIs Help-Seite gibt klar an, dass „PyPI does not support publishing private packages“, private Distributionen gehen also an eine gehostete private Registry oder einen Feed — häufig die Offshore-Cloud eines Anbieters — oder an einen Server, den Sie selbst deployen. Diese privaten Pakete sind proprietärer Quellcode (Geschäftsgeheimnisse) und sie betten regelmäßig Zugangsdaten, API-Token und Konfiguration ein, manchmal Test-Fixture-Personendaten. Im Ausland konzentriert, ist das eine Datenresidenz- und Geschäftsgeheimnis-Exponierung, und wo personenbezogene Daten eingebettet sind, ein grenzüberschreitender Transfer nach PIPL. Die saubere Lösung ist, diesen Speicher im Inland auf einem selbstgehosteten Private-Index zu halten.

Kann 21YunBox helfen, unseren privaten Python-Index in China rechtskonform zu betreiben?

Ja. Unser China-Team kartiert, welche Ihrer Pakete privat sind, ob sie Zugangsdaten, Token oder personenbezogene Daten einbetten, wo diese Registry heute gehostet ist und wie Ihr China-Build seine Abhängigkeiten auflöst — und hilft Ihnen dann, private Pakete, Artefakte und Secrets resident zu halten, indem Sie einen selbstgehosteten Private-Index im Inland betreiben (zum Beispiel ein selbst verwaltetes devpi, Nexus oder Artifactory auf Festland-Infrastruktur) und Ihren Build darauf richten, ohne Wechsel weg von PyPI für öffentliche Abhängigkeiten. Wir stellen dann ICP-gemeldete, inländische Auslieferung für die Anwendung vor dem Stack auf, ohne Neuaufbau. Nehmen Sie Kontakt auf, um Ihren konkreten Fall durchzugehen.