Funktioniert npm in China? Data Residency, ICP & Grenzregeln

Was die offizielle npm-Dokumentation über China sagt

Fakt	Primärquelle
In npms eigenen Worten: „With npm private packages, you can use the npm registry to host code that is only visible to you and chosen collaborators." Diese privaten, gescopeten Pakete sind Ihr proprietärer Quellcode — Geschäftsgeheimnisse — und betten routinemäßig Build-Zugangsdaten, API-Tokens und Konfiguration ein. Auf npms gehosteter Registry leben sie offshore; npm veröffentlicht keine Festlandchina-Region (aktuell mit npm bestätigen). Ein Build, der sie auflöst, ist nicht dasselbe wie dieser Code resident.	npm Docs — About private packages, abgerufen 2026-10-13
Ein echter inländischer Pfad existiert: eine selbst gehostete private npm-Registry, die Sie auf Ihrer eigenen Infrastruktur betreiben. Verdaccio dokumentiert sich als „a private npm registry", bei der „all packages that you publish are private and only accessible based in your configuration"; Sonatype Nexus und JFrog Artifactory bieten dasselbe selbstverwaltete Modell. Betreiben Sie es innerhalb des Festlands, und Ihre privaten Pakete, Build-Artefakte und eingebetteten Geheimnisse bleiben resident, mit der Lieferkette Ihres China-Builds im Inland gehalten.	Verdaccio Docs — What is Verdaccio?, abgerufen 2026-10-13
Für einen Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten innerhalb des Festlands gespeichert werden, mit einer Sicherheitsbewertung vor jeder Ausfuhr — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie umnummeriert durch die Novelle von 2025, in Kraft seit 2026-01-01. Private Pakete und Build-Artefakte, die auf einer Registry außerhalb Chinas gehalten werden, haben keine Festland-Grundlage, um das zu erfüllen.	PRC Cybersecurity Law, Article 39 (formerly Article 37); 2025 amendment in force 2026-01-01
Mitwirkenden-Identitäten, Zugriffsprotokolle, eingebettete Geheimnisse und jegliche personenbezogenen Daten innerhalb privater Pakete oder Build-Metadaten, auf einer Registry außerhalb Chinas gehalten, sind ein PIPL-Grenztransfer (Artikel 38–40): der Verarbeiter muss informieren, eine gesonderte Einwilligung einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung.	PRC Personal Information Protection Law, Articles 38–40; CAC cross-border rules (March 2024)

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

Für einen Betrieb auf dem Festland China ist die entscheidende Frage zu npm nicht, ob ein Build in Shanghai ein öffentliches Paket auflösen kann — sie ist, wo Ihre privaten Pakete leben, was sie tragen und auf welcher rechtlichen Grundlage sie dorthin gelangt sind. Open-Source-Abhängigkeiten zu ziehen ist ein Erreichbarkeitsthema, und nicht das, das entscheidet, ob Ihr Setup verteidigbar ist. Ihre privaten, gescopeten npm-Pakete sind anders: sie sind Ihr proprietärer Quellcode — Geschäftsgeheimnisse — und sie betten routinemäßig Build-Zugangsdaten, API-Tokens und Konfiguration ein, mit gelegentlich mitreitenden Fixture-Daten mit Personenbezug. In npms gehostete Registry veröffentlicht, sitzt dieses konzentrierte geistige Eigentum offshore, und die Abhängigkeits-Lieferkette Ihres China-Builds — welcher Code, mit welcher Provenienz und Integrität, in Ihr China-Deployment eintritt — löst über die Grenze auf. Residency und grenzüberschreitender Transfer, nicht Ladezeit, sind das, was dies entscheidet.

Funktioniert npm in China? Auf einen Blick

Tür eins — Ihre privaten Pakete sind proprietärer Code, und Residency folgt dort, wo sie gehostet werden

Beginnen Sie mit dem, was die Registry hält, denn das ist das, worauf Chinas Recht antwortet. Die öffentliche npm-Registry zieht Community-Abhängigkeiten, aber das ist nicht der Teil, der dies entscheidet. Ihre privaten, gescopeten Pakete sind der maßgebliche Speicher von Code, den Sie nicht an die Welt veröffentlichen: proprietäre Bibliotheken, interne SDKs und Build-Tooling — ein konzentrierter Ausschnitt Ihres geistigen Eigentums — die routinemäßig eingebackene Zugangsdaten, API-Tokens, Registry-Auth und Konfiguration tragen und manchmal personenbezogene Daten in Test-Fixtures. In npms eigenen Worten: „With npm private packages, you can use the npm registry to host code that is only visible to you and chosen collaborators.”

Dieses Hosting ist der Punkt. Die npm-Registry ist npms gehosteter Dienst, der auf einer Infrastruktur außerhalb Chinas läuft, und npm veröffentlicht keine Festlandchina-Region (etwas, das direkt mit npm zu bestätigen ist, statt es anzunehmen). Wenn Sie ein Betreiber kritischer Informationsinfrastruktur sind oder personenbezogene Daten in Mengen verarbeiten, müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten auf dem Festland gespeichert werden, mit einer Sicherheitsbewertung vor jeder Ausfuhr — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie umnummeriert durch die Novelle von 2025, in Kraft seit 2026-01-01. Eine Registry außerhalb Chinas, die Ihre proprietären Pakete und eingebetteten Geheimnisse hält, hat keine Festland-Grundlage, um das zu erfüllen.

Tür zwei — Mitwirkenden-Identitäten, Geheimnisse und Lieferketten-Provenienz

Die zweite Tür ist PIPL und die Integrität dessen, was in Ihren China-Build eintritt. Private Pakete und die Pipeline um sie herum tragen mehr als Code: Benutzernamen und E-Mail-Adressen derer, die ein Release veröffentlicht, gebaut und befördert haben, Zugriffsprotokolle und jegliche personenbezogenen Daten, die ihren Weg in Paketinhalte oder Build-Metadaten finden. Nach dem Gesetz zum Schutz personenbezogener Daten ist das Halten dieser Daten auf einer Infrastruktur außerhalb des Festlands ein grenzüberschreitender Transfer (Artikel 38–40): der Verarbeiter muss informieren, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Die Geheimnisse und personenbezogenen Daten zu minimieren, die überhaupt erst in Paketinhalte eintreten, ist Teil der Lösung, aber es bewegt den Speicher nicht von selbst. Und weil Ihr China-Build seine Abhängigkeiten von dort auflöst, wo auch immer die Registry läuft, werden die Provenienz und Integrität des Codes, der in Ihr China-Deployment eintritt, ebenfalls über die Grenze geregelt — eine Software-Lieferketten-Exponierung, die eine Konnektivitätsprüfung nie zutage fördert.

Warum eine Erreichbarkeitsprüfung dies verfehlt

Ein „kann mein Build Pakete aus Shanghai auflösen”-Test beantwortet die falsche Frage. Ein Registry-Spiegel oder -Cache, oder Konnektivitäts-Tuning, verändert, wie schnell und wie zuverlässig eine Abhängigkeit auflöst — es verändert nicht, wo Ihre privaten Pakete, ihre eingebetteten Geheimnisse und die Build-Provenienz tatsächlich leben. Ein Setup kann also von innerhalb Chinas vollkommen gesund aussehen, während jedes private Paket, jeder darin eingebackene Token und jeder Mitwirkenden-Datensatz weiterhin offshore sitzt. Die Residency- und Grenz-Fragen oben sind für eine Erreichbarkeitssonde genau deshalb unsichtbar, weil die Pakete weiterhin auflösen — weshalb der Zug, der zählt, das Bewegen des privaten Speichers ins Inland ist, nicht das bloße Erreichbar- oder Gespiegelt-Machen des Speichers außerhalb Chinas. Wir veröffentlichen keine erstanbieterliche Messung der npm-Konnektivität aus dem Inneren Chinas, wir setzen hier also keine Zahlen; es ist etwas, das wir gegen Ihr tatsächliches Setup messen würden, statt es zu behaupten.

Dies ist eine Risikokarte, kein Urteil: ob Sie inländische Speicherung, einen Transfermechanismus, einen überarbeiteten Einwilligungsfluss, eine ICP-Beian für ein öffentlich ausgerichtetes Entwicklerportal oder eine Kombination davon brauchen, hängt davon ab, was Ihre privaten Pakete tragen, wie viel und wer Ihre Mitwirkenden sind — wert, mit Rechtsbeistand geklärt zu werden, bevor Sie bauen.

Der Hebel — kartieren, lokalisieren, ausliefern

Weil eine echte selbst gehostete private Registry für npm existiert, gibt es einen echten inländischen Pfad, und 21YunBox nutzt oder empfiehlt niemals eine Umgehung jeglicher Art.

• Kartieren — inventarisieren, welche Ihrer Pakete privat sind (Ihr proprietärer Code), ob sie Zugangsdaten, Tokens oder Konfiguration einbetten, wo diese private Registry heute gehostet wird, die Residency-Grundlage und wie die Abhängigkeits-Lieferkette Ihres China-Builds die Grenze überquert.
• Lokalisieren / regeln — die private Registry und den Artefaktspeicher im Inland betreiben (selbst gehostet — Verdaccio, oder Nexus / Artifactory in Ihrer eigenen Infrastruktur), sodass der proprietäre Code und die eingebetteten Geheimnisse resident bleiben; die Lieferkette Ihres China-Builds im Inland halten; und minimieren, was die Grenze überquert.
• Ausliefern — eine rechtskonforme, inländische private Registry und Artefaktauslieferung vor (oder an die Stelle von) den Dienst außerhalb Chinas setzen; 21YunBox stellt die inländische Schicht ohne Neuaufbau auf.

Die öffentliche Registry bloß erreichbar oder gespiegelt zu machen ist nicht die Antwort — Ihre privaten Pakete und Geheimnisse sind weiterhin offshore, und sie schneller aufzulösen ändert das nicht. Die private Registry und Artefakte im Inland zu halten ist es.

Wo 21YunBox hineinpasst — ein rechtskonformes Overlay, keine Migration

Sie nutzen npm weiter. Wir fügen das Stück hinzu, das eine Registry außerhalb Chinas nicht selbst bieten kann: eine rechtmäßige, inländische Heimat für eine selbst gehostete private Registry, sodass Ihre proprietären Pakete, Build-Artefakte und eingebetteten Geheimnisse resident bleiben, wo das Recht es verlangt, mit rechtskonformer ICP-eingereichter Auslieferung für den Entwicklerzugang und jedes öffentlich ausgerichtete Portal davor — um Ihr bestehendes Setup herum gesetzt, ohne Neuaufbau, ohne zweite Codebasis und ohne Migration weg von npm. Als Partner der Toolchain, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenz-, Einwilligungs- und Data-Residency-Pflichten gegen Ihre Rechtsperson und Ihre Pipeline und stellt dann die inländische Registry und Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir nutzen oder empfehlen niemals eine Umgehung jeglicher Art.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Grenzüberschreitende Datentransfers nach PIPL
• Chinas Cybersicherheitsgesetz und Datenlokalisierung
• Wie man eine ICP-Beian für China erhält

Häufige Fragen

Können wir npm in China nutzen?

Öffentliche Pakete zu ziehen ist eine Erreichbarkeitsfrage, und nicht die eigentliche. Das entscheidende Problem sind Ihre privaten, gescopeten Pakete — Ihr proprietärer Code, oft mit eingebetteten Zugangsdaten — die auf npms gehosteter Registry offshore sitzen, und die Abhängigkeits-Lieferkette Ihres China-Builds, die über die Grenze auflöst. Beides kann im Inland gehalten werden, indem man eine private Registry selbst hostet; das, nicht die Paket-Erreichbarkeit, ist das, was das Setup verteidigbar macht.

Hostet npm private Pakete auf dem Festland China?

npm veröffentlicht keine Festlandchina-Region für seine gehostete Registry (aktuell mit npm bestätigen), in npm veröffentlichte private Pakete sitzen also auf npms Infrastruktur außerhalb Chinas. Die inländische Alternative ist eine selbst gehostete private Registry — Verdaccio, oder Nexus / Artifactory — auf Ihrer eigenen Infrastruktur innerhalb des Festlands betrieben, die die privaten Pakete, Build-Artefakte und eingebetteten Geheimnisse resident hält.

Kann 21YunBox helfen, unser npm-Setup in China rechtskonform zu machen?

Ja. Unser China-Team kartiert, wo Ihre privaten Pakete und Build-Artefakte leben, welche Geheimnisse und personenbezogenen Daten sie tragen und wie die Lieferkette Ihres China-Builds die Grenze überquert, und stellt dann eine rechtskonforme, inländische private Registry und Auslieferung vor Ihr bestehendes Setup — kein Neuaufbau, keine Migration weg von npm. Nehmen Sie Kontakt auf, um Ihren spezifischen Stack durchzugehen.