Funktioniert GitHub Actions in China? Datenresidenz, ICP und Grenztransfer-Regeln

Was die offizielle GitHub Actions-Dokumentation über China sagt

Fakt	Primärquelle
GitHubs Dokumentation gibt an, dass — mit Ausnahme von Single-CPU-Runnern — jeder GitHub-gehostete Runner eine neue, von GitHub gehostete virtuelle Maschine ist und dass GitHub Linux- und Windows-Runner auf virtuellen Maschinen in Microsoft Azure hostet — Infrastruktur außerhalb Festlandchinas.	GitHub Docs — About GitHub-hosted runners (abgerufen 2026-10-13)
GitHubs Dokumentation definiert einen selbst gehosteten Runner als „a system that you deploy and manage to execute jobs from GitHub Actions on GitHub“ (ein System, das Sie bereitstellen und verwalten, um Jobs aus GitHub Actions auf GitHub auszuführen), und gibt an: „You can host your own runners and customize the environment used to run jobs in your GitHub Actions workflows“ (Sie können eigene Runner hosten und die Umgebung anpassen, in der Jobs in Ihren GitHub-Actions-Workflows laufen) — ein inländischer, selbst verwalteter Runner ist also eine First-Party-Option.	GitHub Docs — About self-hosted runners (abgerufen 2026-10-13)
Für einen Betreiber kritischer Informationsinfrastruktur müssen in Festlandchina erhobene und erzeugte personenbezogene Daten und wichtige Daten innerhalb des Festlands gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel jetzt in Art. 39 (vormals Art. 37) nach der Novelle 2025, in Kraft seit 2026-01-01.	Cybersicherheitsgesetz der Volksrepublik China, Art. 39 (vormals Art. 37) (abgerufen 2026-10-13)
Runnerseitige personenbezogene Daten — die Identitäten und E-Mails derjenigen, die einen Lauf ausgelöst haben, plus Build-Logs — auf Infrastruktur außerhalb des Festlands zu halten, ist ein grenzüberschreitender Transfer nach PIPL (Art. 38–40), der Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus erfordert (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung).	Gesetz zum Schutz personenbezogener Daten der Volksrepublik China, Art. 38–40 (abgerufen 2026-10-13)

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

Für ein Festlandchina-Deployment ist die entscheidende Frage zu GitHub Actions nicht, ob ein Runner in Shanghai GitHub erreichen oder eine öffentliche Abhängigkeit ziehen kann — sondern, wo Ihr Quellcode, Ihre Secrets und Ihre Build-Artefakte in dem Moment liegen, in dem der Workflow läuft. Jeder Workflow-Lauf checkt Ihren proprietären Quellcode auf den Runner aus, injiziert Ihre Secrets — Deploy-Keys, Cloud-Anmeldedaten, Signing-Keys, Registry-Token — in die Laufumgebung und erzeugt dort Ihre Build-Artefakte. Auf GitHub-gehosteten Runnern läuft diese Arbeit auf virtuellen Maschinen, die GitHub in Microsoft Azure hostet, außerhalb des Festlands: Ihr konzentrierter Quellcode, Ihre Secrets und Ihre Artefakte verlassen China, und die Build-und-Deploy-Pipeline Ihres China-Deployments überquert die Grenze. Residenz und grenzüberschreitender Transfer, nicht die Runner-Konnektivität, entscheiden darüber, ob das verteidigbar ist.

Funktioniert GitHub Actions in China? Auf einen Blick

Tür eins — Ihr Quellcode-Checkout ist proprietärer Code, und die Residenz folgt dem Ort, an dem der Runner läuft

Beginnen Sie mit dem, was der Runner hält, denn darauf antwortet Chinas Recht. Ein GitHub-Actions-Job greift nicht aus sicherer Entfernung auf Ihren Code zu; er checkt Ihr Repository auf die eigene Platte des Runners aus, eine konzentrierte Kopie Ihres proprietären Quellcodes, die dann in der Laufumgebung neben allem sitzt, was der Job berührt. Auf GitHub-gehosteten Runnern ist diese Umgebung in GitHubs eigenen Worten „a new virtual machine (VM) hosted by GitHub“ (eine neue, von GitHub gehostete virtuelle Maschine) auf „virtual machines in Microsoft Azure“ (virtuellen Maschinen in Microsoft Azure) — Infrastruktur außerhalb des Festlands, ohne veröffentlichte Festland-China-Region für die gehosteten Runner (eher mit GitHub 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 Runner, der Ihren Quellcode auf eine Offshore-VM auscheckt, hat keine Festland-Grundlage, um das zu erfüllen.

Tür zwei — injizierte Secrets, Build-Artefakte und die Lieferkette Ihres Deployments

Die zweite Tür ist PIPL und die Integrität dessen, was tatsächlich ins Festland ausgeliefert wird. Ein Workflow-Lauf trägt weit mehr als Quellcode: Er injiziert Ihre Secrets — den eingebauten GITHUB_TOKEN, Deploy-Keys, Cloud- und Signing-Anmeldedaten, Registry-Token — in die Laufumgebung, er zeichnet Benutzername und E-Mail derjenigen auf, die den Lauf gepusht oder ausgelöst haben, er behält Build-Logs und er gibt die Artefakte aus, die Sie bereitstellen. Nach dem Gesetz zum Schutz personenbezogener Daten ist es ein grenzüberschreitender Transfer (Art. 38–40), diese Akteurdaten und diese Logs auf Infrastruktur außerhalb des Festlands zu halten: 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. Secrets einzugrenzen und zu trimmen, was der Lauf aufzeichnet, ist Teil der Lösung, verschiebt die Laufumgebung aber nicht von allein. Und weil Ihr Festland-Release auf dem Runner gebaut und signiert wird, der den Job ausführt, werden die Herkunft und Integrität dessen, was in China läuft — aus welchem Quellcode, mit welchen Secrets, welches Artefakt erzeugend — ebenfalls über die Grenze geregelt: eine Software-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 GitHub from Shanghai“ (kann mein Runner GitHub aus Shanghai erreichen) beantwortet die falsche Frage. Konnektivitäts-Tuning ändert, wie schnell und wie zuverlässig ein Job startet und seine Abhängigkeiten zieht — es ändert nicht, wo Ihr Quellcode ausgecheckt, wo Ihre Secrets injiziert oder wo Ihre Artefakte erzeugt werden. Eine Pipeline kann also aus China heraus vollkommen grün aussehen, während jeder Checkout, jedes injizierte Secret und jedes Artefakt weiterhin auf einer Offshore-VM in Azure ausgeführt wird. Die Residenz- und Grenztransfer-Fragen oben sind für eine Erreichbarkeits-Sonde gerade deshalb unsichtbar, weil die Jobs weiterlaufen — weshalb der Zug, auf den es ankommt, darin besteht, den Runner im Inland zu betreiben, nicht den Offshore-Runner bloß erreichbar zu machen. Wir veröffentlichen keine eigene Messung der GitHub-Actions-Konnektivität aus China, daher setzen wir hier keine Zahlen; das ist etwas, das wir an Ihrer tatsächlichen Pipeline 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 Workflows auschecken, welche Secrets sie halten und wer sie auslöst — zu klären mit Rechtsbeistand, bevor Sie bauen.

Der Hebel — kartieren, lokalisieren, ausliefern

Weil ein echter selbst gehosteter Runner-Weg existiert — ein System, das Sie bereitstellen und verwalten —, gibt es eine echte Inland-Route, und 21YunBox verwendet oder empfiehlt niemals eine Umgehung welcher Art auch immer.

• Kartieren — inventarisieren, welche Workflows proprietären Quellcode auschecken, welche Secrets jeder Lauf hält (GITHUB_TOKEN, Deploy-Keys, Cloud- und Signing-Anmeldedaten, Registry-Token), wo Ihre Runner und Ihr Artefakt-Speicher heute liegen, die Residenzgrundlage und welche Pipelines in Festland-Infrastruktur bauen und ausliefern.
• Lokalisieren / steuern — Ihre Runner im Inland betreiben (selbst gehostete Runner, das System, das Sie bereitstellen und verwalten), sodass der Checkout, die injizierten Secrets und die Build-Artefakte resident bleiben; die China-Deployment-Pipeline im Inland halten; und minimieren, was die Grenze überquert.
• Ausliefern — rechtskonforme, inländische selbst gehostete Runner vor die (oder an die Stelle der) Offshore-Steuerebene setzen; 21YunBox baut die Inland-Schicht ohne Neuaufbau auf.

Den gehosteten Runner bloß erreichbar zu machen, ist nicht die Antwort — Ihr Quellcode, Ihre Secrets und Artefakte werden weiterhin offshore ausgeführt, und ein schnellerer Job-Start ändert das nicht. Den Checkout, die Secrets und die Artefakte im Inland zu halten, ist die Antwort.

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

Sie nutzen weiter GitHub und die Workflows, die Sie bereits geschrieben haben. Wir ergänzen das Stück, das ein gehosteter Runner nicht allein bieten kann: ein rechtmäßiges, inländisches Zuhause für selbst gehostete Runner, sodass Ihr Quellcode-Checkout, 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 Wechsel weg von GitHub Actions. 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 eine Umgehung welcher Art auch immer.

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

Können wir einfach GitHub-gehostete Runner aus China heraus nutzen?

Erreichbarkeit ist nicht das entscheidende Thema. Auf GitHub-gehosteten Runnern wird Ihr proprietärer Quellcode ausgecheckt, Ihre Secrets werden injiziert und Ihre Artefakte werden auf virtuellen Maschinen erzeugt, die GitHub in Microsoft Azure hostet, außerhalb des Festlands. Diese Konzentration von Quellcode, Secrets und Artefakten offshore ist eine Datenresidenz-Frage nach dem Cybersicherheitsgesetz, Art. 39 (vormals Art. 37), und ein PIPL-Grenztransfer, unabhängig davon, wie schnell der Job startet.

Was ist ein selbst gehosteter Runner, und behebt er das Residenzproblem?

GitHub definiert einen selbst gehosteten Runner als ein System, das Sie bereitstellen und verwalten, um Jobs aus GitHub Actions auszuführen. Weil Sie es bereitstellen und verwalten, wählen Sie, wo es läuft: Betreiben Sie es auf Ihren eigenen Maschinen im Inland, und der Checkout, die injizierten Secrets und die Build-Artefakte bleiben im Festland resident. Das ist der Hebel — er hält die sensiblen Teile des Laufs im Inland, statt Ihren Code und Ihre Secrets offshore zu verschieben.

Ist das ein PIPL-Problem oder ein Problem des Cybersicherheitsgesetzes?

Es kann beides sein. Die Lokalisierungspflicht des Cybersicherheitsgesetzes — Art. 39 (vormals Art. 37) — reicht an Quellcode und wichtige Daten für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen, während PIPL Art. 38–40 die Akteur-Identitäten und Logs, die ein Lauf hält, als grenzüberschreitenden Transfer regeln. Ob und welchen Mechanismus Sie brauchen, hängt von Ihrer Rechtsperson, Ihren Datenmengen und davon ab, wer Ihre Workflows auslöst — klären Sie es mit Rechtsbeistand, bevor Sie bauen.