Funktioniert JFrog Artifactory in China? Data Residency, ICP & Grenztransfer-Regeln
JFrog Artifactory ist Ihr Binär-Artefakt-Repository — Build-Artefakte, die lizenzierten Code, Geheimnisse und Build-Provenienz einbetten können, plus Beitragenden-Metadaten. Auf JFrog Cloud (SaaS) sitzt dieser Speicher offshore: eine PIPL-Grenztransfer- und Datenlokalisierungsfrage, keine Erreichbarkeitsfrage. Artifactory ist selbst hostbar (Self-Managed / On-Prem), Sie können es also auf inländischer Infrastruktur betreiben und die Artefakte ansässig halten.
Funktioniert JFrog Artifactory in China?
Die eigentliche Frage ist nicht, ob Entwickler JFrog Artifactory aus Schanghai erreichen können — es ist, dass das Repository, seine eingebetteten Geheimnisse und Build-Provenienz und die Control Plane, die sie hält, dort leben, wo immer der Server läuft. Artifactory ist ein konzentrierter Speicher geistigen Eigentums: Build-Artefakte, die lizenzierten/proprietären Code, Pipeline-Geheimnisse und Signiermaterial einbetten können, plus jede Beitragenden-Metadaten. Auf JFrog Cloud (SaaS) sitzt dieser Speicher auf offshore gelegenen Public-Cloud-Regionen, ohne Festlandchina-Region in JFrogs veröffentlichten Materialien.
Offshore gehalten, sind Beitragenden-Identitäten und jede personenbezogene Information in Commits oder Build-Metadaten ein PIPL-Grenztransfer (Artikel 38–40); für einen CIIO oder Handler mit hohem Volumen ist die Datenlokalisierungsregel des Cybersicherheitsgesetzes (Artikel 39 (vormals Artikel 37)) im Spiel. Ein selbstgehosteter Runner führt nur Jobs aus — er bewegt den Speicher nicht ins Inland.
Weil Artifactory eine Self-Managed- / On-Prem-Edition liefert, gibt es eine echte Lösung: betreiben Sie es auf inländischer Infrastruktur, sodass die Artefakte, Geheimnisse und Findings ansässig bleiben. 21YunBox ist ein Partner für die Plattform, die Sie bereits betreiben — wir nutzen oder empfehlen niemals Umgehung. Behandeln Sie die Einzelheiten als mit Rechtsbeistand zu bestätigendes Risiko.
Compliance-Momentaufnahme
- ! Artifactory ist ein konzentrierter IP-Speicher: Artefakte, Geheimnisse, Build-Provenienz.
- ! Offshore betrieben, sitzen dieser Speicher und jede Beitragenden-Daten außerhalb des Festlands.
- ! Beitragenden-/Commit-PII offshore ist ein PIPL-Art.-38–40-Grenztransfer.
- ! CIIO oder hohes Volumen löst Datenlokalisierung aus: CSL Art. 39 (vormals Art. 37).
- ! Ein selbstgehosteter Runner ist nicht die Control Plane; der Speicher bleibt, wo der Server läuft.
- ✓ Hebel: Self-Managed Artifactory im Inland betreiben, um die Artefakte ansässig zu halten.
Was die offizielle JFrog Artifactory-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| JFrog dokumentiert eine selbstverwaltete Edition, die Sie auf Ihrer eigenen Infrastruktur installieren. JFrogs Self-Managed-Pro-/Pro-X-Start-Guide gibt an: „This guide will cover setting up a self-managed Artifactory and Xray with all the steps in one place.“ Diese selbstverwaltete Edition ist der Residency-Hebel — auf inländischer Infrastruktur betrieben, bleiben die Artefakte und Geheimnisse ansässig. | JFrog — Self-Managed Pro / Pro X Start Guide (jfrog.com/help), abgerufen 2026-10-12 |
| JFrogs eigene Referenzarchitektur rahmt SaaS als Standard und Self-Managed als die On-Prem-Alternative. Die JFrog Platform Reference Architecture beschreibt die Self-Managed-Option als „A fully self-managed installation and configuration of the JFrog Platform“, mit Bereitstellungszielen einschließlich eines privaten Rechenzentrums, und rät „Unless not possible, it is highly recommended to choose the JFrog SaaS option.“ JFrog Cloud (SaaS) läuft auf offshore gelegenen Public-Cloud-Regionen; JFrogs veröffentlichte Materialien nennen keine Festlandchina-Region (bestätigen Sie die aktuellen Regionen mit JFrog). | JFrog Platform Reference Architecture — Self-Managed (jfrog.com), abgerufen 2026-10-12 |
| Beitragenden- und Commit-Daten, offshore gehalten, sind ein PIPL-Grenztransfer. Personenbezogene Information — Beitragenden-Identitäten und jede personenbezogene Information in Commits, Issues oder Build-Metadaten — auf Infrastruktur außerhalb des Festlands zu halten, löst PIPL Artikel 38–40 aus: Mitteilung, eine gesonderte Einwilligung für den Transfer und einen Mechanismus (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder Zertifizierung). | Cross-border data transfers under PIPL — 21YunBox compliance reference, abgerufen 2026-10-12 |
| CIIOs und Handler mit hohem Volumen stehen vor einer inländischen Speicherpflicht. Das Cybersicherheitsgesetz verlangt, dass von Betreibern kritischer Informationsinfrastruktur in China erhobene und generierte personenbezogene Information und important data innerhalb des Territoriums gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — Artikel 39 (vormals Artikel 37), wie durch die Novelle von 2025, in Kraft seit 2026-01-01, umnummeriert. | China's Cybersecurity Law and data localization — 21YunBox compliance reference, abgerufen 2026-10-12 |
Quellen vom 21YunBox Compliance-Team am 12. Oktober 2026 geprüft.
Für eine Festlandchina-Operation ist die entscheidende Frage zu JFrog Artifactory nicht, ob ein Entwickler in Schanghai die Web-UI laden kann — es ist, wo die Binaries, Geheimnisse und Build-Datensätze, die Artifactory hält, leben dürfen, und auf welcher Rechtsgrundlage sie dorthin gelangt sind. Artifactory ist Ihr Binär-Artefakt-Repository: der einzige Speicher für die Build-Ausgaben, Container-Images, Pakete und Release-Bundles, die lizenzierten und proprietären Code, Pipeline-Geheimnisse, Signiermaterial und Build-Provenienz einbetten können — eine konzentrierte Scheibe Ihres geistigen Eigentums — neben jeder Beitragenden-Metadaten, die in der Pipeline mitreitet. Betreiben Sie diesen Speicher offshore, und das konzentrierte geistige Eigentum sitzt außerhalb des Festlands; was Residency und grenzüberschreitenden Transfer, nicht die Ladezeit, zu dem macht, was entscheidet, ob das Setup verteidigbar ist.
Funktioniert JFrog Artifactory in China? Auf einen Blick
| Was darüber entscheidet | Was es für Festlandchina bedeutet |
|---|---|
| Was Artifactory hält | Build-Artefakte, Container-Images und Release-Bundles, die lizenzierten/proprietären Code, Pipeline-Geheimnisse, Signiermaterial und Build-Provenienz einbetten können — ein konzentrierter Speicher Ihres geistigen Eigentums, plus jede Beitragenden-Metadaten in der Pipeline. |
| Wo die Control Plane läuft | Auf JFrog Cloud (SaaS) laufen das Repository, die Metadaten und die Control Plane auf JFrogs offshore gelegenen Public-Cloud-Regionen. JFrogs veröffentlichte Materialien nennen keine Festlandchina-Region (bestätigen Sie die aktuellen Regionen mit JFrog). |
| Data Residency | Für einen CIIO oder Handler mit hohem Volumen müssen in China erhobene personenbezogene Information und important data im Festland gespeichert werden (Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)) — eine Pflicht, die offshore gelegene Infrastruktur nicht erfüllen kann. |
| Grenzüberschreitender Transfer | Beitragenden-Identitäten und jede personenbezogene Information in Commits, Issues oder Build-Metadaten, offshore gehalten, sind ein PIPL-Grenztransfer (Artikel 38–40): Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus. |
| Ein selbstgehosteter Runner ist nicht genug | Ein Build-Agent oder Runner führt nur Jobs aus. Die Verbindung eines Entwicklers oder die UI erreichbar zu machen, bewegt das Repository, die Geheimnisse oder die Provenienz nicht ins Inland — der Speicher lebt weiterhin, wo immer der Server läuft. |
| Der Residency-Hebel | Artifactory liefert eine Self-Managed- / On-Prem-Edition. Betreiben Sie es auf inländischer Infrastruktur, und die Artefakte, Geheimnisse und Findings bleiben ansässig — der eine Zug, der die Residency-Frage tatsächlich beantwortet. |
Tür eins — Artifactory ist ein konzentrierter Speicher Ihres geistigen Eigentums, und Residency folgt dem, wo es läuft
Beginnen Sie mit dem, was das Repository hält, denn das ist es, worauf Chinas Recht reagiert. Artifactory ist kein Cache öffentlicher Pakete; es ist der maßgebliche Speicher für Ihre Build-Ausgaben — Container-Images, Sprachpakete, Release-Bundles und die Metadaten darum. Diese Artefakte betten routinemäßig lizenzierten und proprietären Code, eingebackene Pipeline-Geheimnisse und -Zugangsdaten, Signierschlüssel und die Build-Provenienz ein, die genau festhält, wie Ihre Software zusammengebaut wurde. Das ist eine konzentrierte Scheibe Ihres geistigen Eigentums, die an einem Ort sitzt.
Betreiben Sie diesen Speicher auf JFrog Cloud (SaaS), und er lebt auf JFrogs offshore gelegenen Public-Cloud-Regionen; nach JFrogs veröffentlichten Materialien gibt es keine Festlandchina-Region (etwas, das direkt mit JFrog zu bestätigen ist, statt es anzunehmen). Wenn Sie ein Betreiber kritischer Informationsinfrastruktur sind oder personenbezogene Information im Volumen verarbeiten, müssen in China erhobene und generierte personenbezogene Information und important data im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie durch die Novelle von 2025, in Kraft seit 2026-01-01, umnummeriert. Offshore gelegene Infrastruktur hat kein Festland-Fundament, um das zu erfüllen.
Tür zwei — Beitragenden-Identitäten und Commit-Daten sind personenbezogene Information
Die zweite Tür ist PIPL. Artifactory und die Pipeline darum tragen mehr als Binaries: Benutzernamen und E-Mail-Adressen dazu, wer einen Release gepusht, gebaut und promoviert hat, Zugriffslogs und jede personenbezogene Information, die ihren Weg in Commit-Nachrichten, Issue-Referenzen oder Build-Metadaten findet. Nach dem Gesetz zum Schutz personenbezogener Daten ist das Halten dieser Daten auf Infrastruktur außerhalb des Festlands ein grenzüberschreitender Transfer (Artikel 38–40): der Handler muss Mitteilung geben, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus klären — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder Zertifizierung. Die personenbezogenen Daten zu minimieren, die überhaupt in Commits und Build-Metadaten gelangen, ist Teil der Lösung, aber es bewegt den Speicher nicht von sich aus.
Warum ein Erreichbarkeits-Check das verfehlt
Ein „können meine Entwickler es aus Schanghai erreichen“-Test beantwortet die falsche Frage. Konnektivitäts-Tuning, oder einen selbstgehosteten Build-Runner innerhalb des Festlands aufzustellen, ändert, wie ein Job den Server erreicht — es ändert nicht, wo das Repository, der Geheimnis-Tresor, der Artefakt-Speicher und die Build-Provenienz tatsächlich leben. Ein Runner führt Jobs aus; er ist nicht die Control Plane. Ein Setup kann also von innerhalb Chinas vollkommen gesund aussehen, während jedes Artefakt, Geheimnis und jeder Provenienz-Datensatz weiterhin offshore sitzt, und jeder Beitragenden-Datensatz mit ihm. Die Residency- und Grenzfragen oben sind für eine Erreichbarkeitssonde unsichtbar, gerade weil die Binaries weiterhin auflösen — weshalb der Zug, der zählt, ist, den Speicher zu bewegen, nicht den offshore gelegenen Speicher erreichbar zu machen. Wir veröffentlichen keine First-Party-Messung der Artifactory-Konnektivität von innerhalb Chinas, wir bringen hier also keine Zahlen an; es ist etwas, das wir gegen Ihre tatsächliche Instanz 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 jedes öffentlich zugängliche Entwicklerportal oder eine Kombination brauchen, hängt davon ab, was Ihre Artefakte und Ihre Pipeline tragen, wie viel und wer Ihre Beitragenden sind — wert, mit Rechtsbeistand geklärt zu werden, bevor Sie bauen.
Der Hebel — kartieren, lokalisieren, ausliefern
Weil Artifactory eine Self-Managed- / On-Prem-Edition liefert, gibt es einen echten inländischen Pfad, und 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art.
- Kartieren — inventarisieren, was Ihr Artifactory hält (Artefakte, Container-Images, eingebettete Geheimnisse, Signiermaterial, Build-Provenienz, Beitragenden-Metadaten), wo der Server und die Control Plane heute laufen, die Residency-Grundlage und ob das konzentrierte geistige Eigentum und die personenbezogenen Daten die inländische Speicherpflicht berühren.
- Lokalisieren / regieren — die Self-Managed-Edition auf inländischer Infrastruktur betreiben, sodass die Artefakte, Geheimnisse und Build-Datensätze ansässig bleiben; die personenbezogenen Daten minimieren, die in Commits und Build-Metadaten gelangen; und die Control Plane regieren, statt sie bloß zu exponieren.
- Ausliefern — rechtskonformen, inländischen Entwicklerzugang vor die selbstverwaltete Instanz setzen, die Sie bereits betreiben, sodass Ihre Teams sie zuverlässig erreichen, ohne den Speicher zurück über die Grenze zu bewegen.
Den offshore gelegenen Server bloß erreichbar zu machen, ist nicht die Antwort — die Artefakte, Geheimnisse, Provenienz und Beitragenden-Datensätze sind weiterhin offshore, und ein selbstgehosteter Runner ändert das nicht. Die Self-Managed-Edition im Inland zu betreiben, ist es.
Wo 21YunBox hineinpasst — eine rechtskonforme Overlay, keine Migration
Sie betreiben weiter JFrog Artifactory. Wir fügen das Stück hinzu, das ein offshore gelegener Artefakt-Speicher nicht von sich aus bieten kann: ein rechtmäßiges, inländisches Zuhause für die selbstverwaltete Bereitstellung, sodass Ihre Binaries, Geheimnisse und Build-Provenienz ansässig bleiben, wo das Gesetz es verlangt, mit rechtskonformer ICP-beian-pflichtiger Auslieferung für den Entwicklerzugang und jedes öffentlich zugängliche Portal davor — um Ihr bestehendes Setup herum platziert, ohne Neuaufbau, ohne zweite Codebasis und ohne Migration weg von Artifactory. Als Partner für die Plattform, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenztransfer-, Einwilligungs- und Data-Residency-Pflichten gegen Ihre Rechtsperson und Ihre Pipeline und stellt dann die inländische Bereitstellung und Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir nutzen oder empfehlen niemals Umgehung jeglicher Art.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Ist JFrog Artifactory in China gesperrt?
Sperrung ist die falsche Achse. JFrog Cloud (SaaS) wird grenzüberschreitend erreicht und die Konnektivität kann uneben sein, aber die Frage, die Gewicht trägt, ist nicht Erreichbarkeit — es ist, dass Ihr Repository, Ihre eingebetteten Geheimnisse und Build-Provenienz und die Control Plane, die sie hält, dort leben, wo immer der Server läuft. Auf SaaS ist das offshore. Weil es dort direkt erreicht wird, gibt es nichts zu umgehen, und wir nutzen oder empfehlen niemals Umgehung. Bestätigen Sie die Einzelheiten mit Rechtsbeistand.
Kann ich meine Build-Artefakte und Geheimnisse innerhalb Festlandchinas halten?
Ja — das ist der Sinn der selbstverwalteten Edition. Artifactory liefert einen Self-Managed- / On-Prem-Build, den Sie auf Ihrer eigenen Infrastruktur installieren, Sie können es also auf inländischer Infrastruktur betreiben und die Artefakte, Pipeline-Geheimnisse, das Signiermaterial und die Build-Provenienz ansässig halten. Das ist der Zug, der die Data-Residency- und Grenzfragen tatsächlich beantwortet; ein selbstgehosteter Runner allein tut es nicht, weil er nur Jobs ausführt und den Speicher nicht bewegt.
Macht ein selbstgehosteter Build-Runner innerhalb Chinas Artifactory rechtskonform?
Nein. Ein Runner oder Build-Agent führt Jobs aus; er ist nicht die Control Plane. Einen innerhalb des Festlands aufzustellen, ändert, wie ein Job den Server erreicht, nicht, wo das Repository, die Geheimnisse, die Provenienz und die Beitragenden-Datensätze leben. Wenn der Artifactory-Server offshore läuft, ist all das weiterhin offshore. Der rechtskonforme Zug ist, den selbstverwalteten Artifactory-Server selbst auf inländischer Infrastruktur zu betreiben — den 21YunBox als Partner für die Plattform, die Sie bereits betreiben, aufstellen kann.
