Funktioniert GitLab CI/CD in China? Datenresidenz, ICP und Grenztransfer-Regeln

Was die offizielle GitLab CI/CD-Dokumentation über China sagt

Fakt	Primärquelle
In GitLabs eigenen Worten: „GitLab-hosted runners are managed by GitLab and available on GitLab.com“ (GitLab-gehostete Runner werden von GitLab verwaltet und sind auf GitLab.com verfügbar), und GitLab „provides them as a service“ (stellt sie als Dienst bereit) — seine eigene Infrastruktur —, wohingegen „Self-managed runners are GitLab Runner instances that you install, configure, and manage in your own infrastructure“ (selbst verwaltete Runner GitLab-Runner-Instanzen sind, die Sie in Ihrer eigenen Infrastruktur installieren, konfigurieren und verwalten), und „You can install and register self-managed runners on all GitLab installations“ (Sie können selbst verwaltete Runner auf allen GitLab-Installationen installieren und registrieren). Die gehosteten Runner, die Ihren Quellcode auschecken und Ihre Secrets ausführen, sind also GitLabs Offshore-Dienst, und der Inland-Residenz-Weg ist ein selbst gehosteter Runner, den Sie selbst betreiben.	GitLab Docs — GitLab Runner, abgerufen 2026-10-13
Ein CI/CD-Job erreicht nicht nur einen Dienst — er hält Ihren Quellcode und Ihre Secrets, während er läuft. GitLabs Dokumentation beschreibt CI/CD-Variablen als „a type of environment variable“ (eine Art Umgebungsvariable), die Sie nutzen, um „store values you want to re-use, for example in job scripts“ (Werte zu speichern, die Sie wiederverwenden möchten, zum Beispiel in Job-Skripten): der Mechanismus, der Deploy-Keys, Cloud-Anmeldedaten, Signing-Keys und Registry-Token in die Laufumgebung injiziert. Auf einem gehosteten Runner werden diese Umgebung und der proprietäre Quellcode, der daneben ausgecheckt wird, auf GitLabs Offshore-Infrastruktur ausgeführt.	GitLab Docs — CI/CD variables, abgerufen 2026-10-13
Weil ein gehosteter Runner die Identitäten Ihrer Committer, Job-Logs und alle personenbezogenen Daten in Artefakten oder Variablen hält und sie auf Infrastruktur außerhalb des Festlands ausführt, ist das ein grenzüberschreitender Transfer personenbezogener Daten. PIPL regelt ihn (Art. 38–40): Der Verarbeiter personenbezogener Daten (Sie, die GitLab-Kundin) muss Mitteilung erteilen, gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung.	Gesetz zum Schutz personenbezogener Daten, Art. 38–40
Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen müssen in Festlandchina erhobene und erzeugte personenbezogene Daten und wichtige Daten im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Art. 39 (vormals Art. 37) in der Nummerierung der Novelle 2025, in Kraft seit 2026-01-01. Ein offshore gehosteter Runner, der Ihren Quellcode auscheckt und Ihre Secrets ausführt, hat keine Festland-Grundlage, um das zu erfüllen.	Cybersicherheitsgesetz der VR China, Art. 39 (vormals Art. 37)

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

Für ein Festlandchina-Deployment ist die entscheidende Frage zu GitLab CI/CD nicht, ob ein Runner in Shanghai GitLab erreichen oder eine öffentliche Abhängigkeit ziehen kann — sondern, wo Ihr Quellcode, Ihre Build- und Deploy-Secrets und Ihre Build-Artefakte in dem Moment liegen, in dem die Pipeline läuft. Den Dienst zu erreichen und Abhängigkeiten aufzulösen, sind Erreichbarkeitsthemen, und Konnektivitäts-Tuning kann ihnen helfen; sie sind nicht der Teil, der darüber entscheidet, ob Ihr Setup verteidigbar ist. Ein CI/CD-Job ist anders. Jeder Job checkt Ihren proprietären Quellcode in den Workspace des Runners aus, injiziert dann Ihre Secrets — Deploy-Keys, Cloud-Anmeldedaten, Signing-Keys und Registry-Token — in die Laufumgebung und erzeugt Build-Artefakte. Auf den gehosteten Runnern von GitLab.com werden dieser konzentrierte Quellcode, diese Secrets und diese Artefakte allesamt auf GitLabs eigener Infrastruktur ausgeführt, und die Build-Pipeline Ihres China-Deployments überquert die Grenze. Residenz und grenzüberschreitender Transfer, nicht die Pull-Latenz, entscheiden darüber.

Funktioniert GitLab CI/CD in China? Auf einen Blick

Tür eins — Ihr Quellcode wird in den Runner ausgecheckt, und die Residenz folgt dem Ort, an dem der Runner läuft

Beginnen Sie mit dem, was tatsächlich ausgeführt wird, denn darauf antwortet Chinas Recht. GitLab zu erreichen und ein öffentliches Paket zu ziehen, ist ein Konnektivitätsthema, und es ist nicht der Teil, der darüber entscheidet. Der Job ist es. Wenn eine Pipeline läuft, klont GitLab Runner Ihr privates Repository in den Workspace des Runners — Ihren proprietären Quellcode, Abhängigkeiten und Build-Logik, ein konzentrierter Ausschnitt Ihres geistigen Eigentums. GitLabs eigene Dokumentation beschreibt GitLab-gehostete Runner als „managed by GitLab and available on GitLab.com“ (von GitLab verwaltet und auf GitLab.com verfügbar), wobei GitLab sie „as a service“ (als Dienst) bereitstellt — eine gehostete Flotte, die auf GitLabs eigener Offshore-Infrastruktur läuft, ohne Festland-China-Region für gehostete Runner für Ihre Jobs (eher mit GitLab zu bestätigen als anzunehmen). Sind Sie ein Betreiber kritischer Informationsinfrastruktur oder verarbeiten Sie personenbezogene Daten in großem Umfang, müssen in China erhobene und erzeugte personenbezogene Daten und wichtige Daten im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Art. 39 (vormals Art. 37) in der Nummerierung der Novelle 2025, in Kraft seit 2026-01-01. Ein gehosteter Runner, der Ihren Quellcode im Ausland auscheckt, hat keine Festland-Grundlage, um das zu erfüllen.

Tür zwei — injizierte Secrets, Committer-Identitäten und Ihre Build-Artefakte

Die zweite Tür ist PIPL und die konzentrierten Secrets, die eine Pipeline trägt. Ein CI/CD-Job hält weit mehr als Quellcode: GitLabs Dokumentation beschreibt CI/CD-Variablen als „a type of environment variable“ (eine Art Umgebungsvariable), die Sie nutzen, um „store values you want to re-use, for example in job scripts“ (Werte zu speichern, die Sie wiederverwenden möchten, zum Beispiel in Job-Skripten) — der Mechanismus, der Ihre Deploy-Keys, Cloud-Anmeldedaten, Signing-Keys und Registry-Token in den laufenden Job injiziert. Um sie herum sitzen die Benutzernamen und E-Mail-Adressen derjenigen, die die Pipeline gepusht, geprüft und ausgelöst haben, die Job-Logs und die Build-Artefakte, die der Job schreibt — mit gelegentlich einem personenbezogenen Datensatz, der in einer Fixture oder einem Test-Datensatz mitreist. Nach dem Gesetz zum Schutz personenbezogener Daten ist es ein grenzüberschreitender Transfer (Art. 38–40), diese Daten auf Infrastruktur außerhalb des Festlands zu halten und zu verarbeiten: Der Verarbeiter muss Mitteilung erteilen, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus erfüllen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Variablen zu maskieren und zu trimmen, was in Logs und Artefakten landet, ist Teil guter Hygiene, verschiebt aber den Runner nicht, der sie ausführt. Und weil Ihr China-Deployment von dem Runner gebaut und ausgeliefert wird, der den Job ausführt, werden die Herkunft und Integrität dessen, was ins Festland ausgeliefert wird — aus welchem Quellcode gebaut, mit welchem Schlüssel signiert —, ebenfalls über die Grenze geregelt: eine Lieferketten-Exponierung, die eine Konnektivitätsprüfung nie zutage fördert.

Warum eine Erreichbarkeitsprüfung das verfehlt

Ein Test nach dem Muster „can my runner reach GitLab from Shanghai“ (kann mein Runner GitLab aus Shanghai erreichen) beantwortet die falsche Frage. Konnektivitäts-Tuning oder ein Abhängigkeits-Cache ändert, wie schnell und wie zuverlässig ein Job startet und seine Pakete auflöst — es ändert nicht, wo Ihr Quellcode ausgecheckt wird, wo Ihre injizierten Secrets ausgeführt werden und wo Ihre Build-Artefakte geschrieben werden. Eine Pipeline kann also aus China heraus vollkommen grün aussehen, während jeder Checkout Ihres proprietären Quellcodes, jeder in den Job injizierte Deploy- und Signing-Key und jeder Committer-Datensatz weiterhin offshore läuft. Die Residenz- und Grenztransfer-Fragen oben sind für eine Erreichbarkeits-Sonde gerade deshalb unsichtbar, weil die Jobs weiter durchlaufen — weshalb der Zug, auf den es ankommt, darin besteht, die Runner im Inland zu betreiben, nicht die gehosteten bloß erreichbar zu machen. Wir veröffentlichen keine eigene Messung der GitLab-Konnektivität aus China, daher setzen wir hier keine Zahlen; das ist etwas, das wir an Ihrem tatsächlichen Setup messen würden, statt es zu behaupten.

Dies ist eine Risikokarte, kein Urteil: Ob Sie Inland-Runner, einen Transfermechanismus, einen überarbeiteten Einwilligungsfluss, eine ICP-Beian für ein öffentlich zugängliches Entwickler- oder Deployment-Portal oder eine Kombination davon brauchen, hängt davon ab, was Ihre Pipelines auschecken, welche Secrets sie halten und wer Ihre Committer sind — zu klären mit Rechtsbeistand, bevor Sie bauen.

Der Hebel — kartieren, lokalisieren, ausliefern

Weil ein echtes selbst verwaltetes GitLab und ein selbst gehosteter GitLab Runner existieren, gibt es einen echten Inland-Weg, und 21YunBox verwendet oder empfiehlt niemals einen rechtswidrigen Behelf — der Inland-Weg ist der rechtmäßige.

• Kartieren — inventarisieren, welche Pipelines proprietären Quellcode auschecken, welche Secrets (Deploy-Keys, Cloud-Anmeldedaten, Signing-Keys, Registry-Token) der Runner hält, wo die Runner und der Artefakt-Speicher heute liegen, die Residenzgrundlage und wie die Build-Pipeline Ihres China-Deployments die Grenze überquert.
• Lokalisieren / steuern — die Runner im Inland betreiben (selbst gehostet — ein selbst verwaltetes GitLab mit selbst gehosteten GitLab Runnern in Ihrer eigenen Infrastruktur), sodass der ausgecheckte Quellcode, die injizierten Secrets und die Build-Artefakte resident bleiben; die Build-Pipeline Ihres China-Deployments im Inland halten; und minimieren, was die Grenze überquert.
• Ausliefern — rechtskonforme, inländische selbst gehostete Runner und eine selbst verwaltete Steuerebene vor die (oder an die Stelle der) gehosteten Offshore-Runner setzen; 21YunBox baut die Inland-Schicht ohne Neuaufbau auf.

Den gehosteten Dienst bloß erreichbar zu machen, ist nicht die Antwort — Ihr Quellcode, Ihre Secrets und Artefakte werden weiterhin offshore ausgeführt, und Jobs schneller zu starten ändert das nicht. Die Runner und das, was sie halten, im Inland zu halten, ist die Antwort.

Wo 21YunBox hineinpasst — eine Compliance-Overlay, keine Migration

Sie nutzen weiter GitLab und Ihre bestehenden Pipelines. Wir ergänzen das Stück, das ein gehosteter Runner nicht allein bieten kann: ein rechtmäßiges, inländisches Zuhause für ein selbst verwaltetes GitLab mit selbst gehosteten GitLab Runnern, sodass Ihr proprietärer Quellcode, die injizierten Secrets und die Build-Artefakte dort resident bleiben, wo das Recht es verlangt, mit rechtskonformer ICP-gemeldeter Auslieferung für den Entwicklerzugang und jedes öffentlich zugängliche Deployment-Portal davor — um Ihr bestehendes Setup herum gelegt, ohne Neuaufbau, ohne zweite Codebasis und ohne Migration weg von GitLab. Als Partnerin der Toolchain, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenztransfer-, Einwilligungs- und Datenresidenzpflichten anhand Ihrer Rechtsperson und Ihrer Pipeline und baut dann die Inland-Runner und -Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir verwenden oder empfehlen niemals einen rechtswidrigen Behelf.

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

Kann mein GitLab-Runner GitLab.com aus China heraus erreichen?

Meist ja, und genau deshalb ist Erreichbarkeit der falsche Test. Ein Job kann aus dem Festland starten und durchlaufen, während Ihr proprietärer Quellcode, die in ihn injizierten Deploy- und Signing-Keys und die Build-Artefakte, die er schreibt, weiterhin offshore auf GitLabs gehosteten Runnern ausgeführt werden. Was darüber entscheidet, ob Ihr Setup verteidigbar ist, ist, wo dieser Quellcode und diese Secrets liegen, wenn die Pipeline läuft — nicht, ob der Runner eine Verbindung aufbauen kann.

Verstößt die Nutzung von GitLab CI/CD in China gegen das Gesetz?

Nicht grundsätzlich. Das Thema ist der grenzüberschreitende Transfer und die Residenz dessen, was die Pipeline hält: Ihr Quellcode, Ihre injizierten Secrets, Committer-Identitäten und Artefakte. PIPL erlaubt einen grenzüberschreitenden Transfer, wenn Sie Mitteilung erteilen, gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen; ob Sie zusätzlich einer Datenlokalisierungspflicht unterliegen, hängt von Ihrer Rolle (etwa ob Sie ein Betreiber kritischer Informationsinfrastruktur sind) und dem Umfang der personenbezogenen Daten ab, die Sie verarbeiten. Behandeln Sie es als ein mit Rechtsbeistand zu bewertendes Risiko, nicht als pauschales Verbot.

Wie halten wir den Quellcode und die Secrets unserer GitLab-Pipeline in China?

Betreiben Sie die Runner im Inland. GitLabs eigene selbst verwaltete Edition plus selbst gehostete GitLab Runner lassen Sie die Flotte auf Ihrer eigenen Infrastruktur im Festland installieren und betreiben, sodass der Checkout, die injizierten Secrets und die Build-Artefakte resident bleiben. 21YunBox baut diese inländische, selbst gehostete Schicht mit ICP-gemeldeter Auslieferung davor auf — um Ihr bestehendes GitLab herum, ohne Neuaufbau. Nehmen Sie Kontakt auf, um Ihren konkreten Fall zu kartieren.