Funktioniert GitHub Enterprise Server in China? Datenresidenz, ICP und Grenztransfer-Regeln
GitHub Enterprise Server ist die selbst hostbare Edition — Sie können sie in Festlandchina betreiben und Repositories, Issues und Mitwirkenden-Daten resident halten. GitHub Enterprise Cloud, das SaaS, hat keine Festland-China-Region. Wo Ihr Quellcode liegt, ist eine PIPL-Residenz- und Grenztransfer-Frage, kein Geschwindigkeitstest.
Funktioniert GitHub Enterprise Server in China?
Ja — GitHub Enterprise Server ist GitHubs selbst hostbare Edition, Sie können es also auf Ihrer eigenen Infrastruktur in Festlandchina betreiben und die Repositories, Issues und die Steuerebene, die sie hält, resident halten. Die eigentliche China-Frage ist nicht, ob Entwickler die Web-Oberfläche aus Shanghai erreichen können — sondern, dass Ihr Quellcode (Geschäftsgeheimnisse, oft mit eingebetteten Anmeldedaten und Mitwirkenden-Daten) und seine Metadaten eine Datenresidenz- und Grenztransfer-Angelegenheit sind, und GitHub Enterprise Server im Inland zu betreiben der Hebel ist, der sie beantwortet.
GitHubs Dokumentation nennt GitHub Enterprise Server „a self-hosted version of the GitHub platform“ (eine selbst gehostete Version der GitHub-Plattform), die Sie in Ihr eigenes On-Premises-Rechenzentrum oder Ihre eigene Cloud bereitstellen — weshalb die Antwort warn ist, nicht no. Die gehostete Edition, GitHub Enterprise Cloud, bietet Datenresidenz nur in der EU, den USA, Australien und Japan, mit keiner Festland-China-Region, sodass der SaaS-Weg den Code offshore lässt. Repositories und Mitwirkenden-Daten im Ausland zu halten, ist ein grenzüberschreitender Transfer nach PIPL Art. 38–40; für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen verlangt Cybersicherheitsgesetz Art. 39 (vormals Art. 37), dass in China erhobene personenbezogene Daten im Festland gespeichert werden.
Dies ist eine Residenz-Risikokarte, kein Urteil, dass GitHub „gesperrt“ sei. Unser China-Team kann Ihre Code-Residenz-Exponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! Auf einem Offshore-Server ruhen Ihre Repos, Issues und Metadaten im Ausland
- ! GitHub Enterprise Cloud listet EU, USA, Australien, Japan — keine Festland-China-Region
- ! Quellcode hält Geschäftsgeheimnisse, eingebettete Anmeldedaten und Mitwirkenden-Daten
- ! Code at rest, nicht UI-Erreichbarkeit, ist die Residenzfrage — PIPL Art. 38–40
- ! Betreiber kritischer Informationsinfrastruktur oder große Mengen? CSL Art. 39 (vormals 37) will China-Daten im Inland
- ✓ GHES ist selbst hostbar — im Inland betreiben und Code und Metadaten resident halten
Was die offizielle GitHub Enterprise Server-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| GitHub Enterprise Server ist selbst hostbar — Sie stellen es auf Ihrer eigenen Infrastruktur bereit, es kann also in Festlandchina leben. GitHubs eigene Dokumentation gibt an, GitHub Enterprise Server sei „a self-hosted version of the GitHub platform“ (eine selbst gehostete Version der GitHub-Plattform) und dass Sie „deploy GitHub Enterprise Server to a virtualization hypervisor within your on-premises datacenter, or to a public cloud service“ (GitHub Enterprise Server auf einem Virtualisierungs-Hypervisor im eigenen Rechenzentrum oder auf einem Public-Cloud-Dienst bereitstellen) können. Diese selbst verwaltete Natur ist der Grund, warum die China-Antwort warn ist, nicht no — das Repository und seine Steuerebene können im Festland sitzen. | GitHub Docs — About GitHub Enterprise Server (docs.github.com), abgerufen 2026-10-12 |
| Die gehostete Edition hat keine Festland-China-Region. GitHub Enterprise Cloud mit Datenresidenz listet seine verfügbaren Regionen als EU, Australien, USA und Japan und speichert GitHub.com-Daten standardmäßig in den USA — keine der Optionen platziert das Repository in Festlandchina. Bei GitHub ist der Inland-Weg der selbst gehostete Server, nicht das SaaS. | GitHub Docs — About GitHub Enterprise Cloud with data residency (docs.github.com), abgerufen 2026-10-12 |
| Repositories und Mitwirkenden-Daten offshore gehalten sind ein grenzüberschreitender Transfer nach PIPL. Quellcode plus die personenbezogenen Daten in Commits, Issues und Mitwirkenden-Profilen über der Grenze sind ein grenzüberschreitender Transfer, geregelt durch PIPL Art. 38–40, die einen rechtmäßigen Transfermechanismus verlangen — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung — plus gesonderte Einwilligung für den Auslandstransfer. | Gesetz zum Schutz personenbezogener Daten der VR China, Art. 38–40 (21YunBox-Übersetzung), abgerufen 2026-10-12 |
| Betreiber kritischer Informationsinfrastruktur und Verarbeiter großer Mengen müssen in China erhobene personenbezogene Daten im Festland halten. Nach dem Cybersicherheitsgesetz Art. 39 (vormals Art. 37) — die Novelle 2025, in Kraft seit 1. Januar 2026, hat den Artikel zur Datenlokalisierung von 37 auf 39 umnummeriert, inhaltlich unverändert — müssen in China erzeugte personenbezogene Daten im Inland gespeichert werden, eine Pflicht, die das Offshore-SaaS nicht erfüllen kann, ein selbst gehostetes GitHub-Enterprise-Server-Deployment aber schon. | Cybersicherheitsgesetz der VR China, Art. 39 (vormals Art. 37) (21YunBox-Übersetzung), abgerufen 2026-10-12 |
Quellen vom 21YunBox Compliance-Team am 12. Oktober 2026 geprüft.
Für ein Unternehmen, das GitHub Enterprise Server für ein Engineering-Team in Festlandchina betreibt, ist die Frage, auf die es ankommt, nicht, ob die Web-Oberfläche aus Shanghai schnell rendert. GitHub Enterprise Server ist der Ort, an dem Ihr konzentriertestes geistiges Eigentum lebt: der Quellcode Ihrer Produkte — Geschäftsgeheimnisse, oft mit darin eingebetteten Anmeldedaten und Token — zusammen mit den Issues, Pull-Request-Diskussionen, Wikis und der Steuerebene, die all das indexiert, sowie der Identität jedes Mitwirkenden, der eine Zeile berührt hat. Betreiben Sie das auf einem Offshore-Server, ruht das gesamte Korpus — und die darin verwobenen personenbezogenen Daten — im Ausland und überquert die Grenze jedes Mal, wenn ein Entwickler klont oder pusht. Die Compliance-Achse ist hier Residenz und grenzüberschreitender Transfer, nicht Latenz. Was GitHub Enterprise Server von den gehosteten Editionen unterscheidet, ist, dass es die selbst hostbare Edition ist — sodass der Hebel, der die China-Frage beantwortet, tatsächlich existiert: Sie können den Server selbst im Festland betreiben und den Code resident halten. Drei Stränge entscheiden: die Residenz- und Grenztransfer-Exponierung des gesamten Code-und-Metadaten-Korpus plus der Mitwirkenden-Daten; die besondere zweite Hälfte, die eine Erreichbarkeitsprüfung nie sieht — dass die Repositories, Issues und die Steuerebene selbst, nicht bloß der Zugriff darauf, im Ausland sitzen; und die DevOps-Lektion, dass ein selbst gehosteter Runner nur Jobs ausführt und den Code nie ins Inland verschiebt.
GitHub Enterprise Server in China auf einen Blick
| Worüber es entscheidet | In GitHubs eigenen Worten — und nach chinesischem Recht |
|---|---|
| Was es hält | Ihr konzentriertestes geistiges Eigentum: den Quellcode Ihrer Produkte (Geschäftsgeheimnisse, oft mit darin eingebetteten Anmeldedaten und Token), die Issues, Pull-Request-Diskussionen und Wikis, die Steuerebene, die sie indexiert, und die Identität jedes Mitwirkenden — Namen und E-Mail-Adressen in jedem Commit. Wo diese eine Person benennen oder beschreiben, sind sie personenbezogene Daten. |
| Selbst hostbar — der Hebel (die Prämisse) | GitHub Enterprise Server ist die selbst gehostete Edition: GitHubs Dokumentation nennt es „a self-hosted version of the GitHub platform“ (eine selbst gehostete Version der GitHub-Plattform), das Sie „to a virtualization hypervisor within your on-premises datacenter, or to a public cloud service“ (auf einem Virtualisierungs-Hypervisor im eigenen Rechenzentrum oder auf einem Public-Cloud-Dienst) bereitstellen. Das bedeutet, Sie können es in Festlandchina betreiben und den Code resident halten. Im Gegensatz dazu listet die gehostete Edition, GitHub Enterprise Cloud, Datenresidenz-Regionen nur in der EU, den USA, Australien und Japan — keine Festland-China-Region. |
| Das gesamte Code-Korpus offshore — die besondere zweite Hälfte | Die Hälfte, die eine Erreichbarkeitsprüfung nie sieht. Es geht nicht darum, ob Ihr Team die Web-Oberfläche aus Shanghai öffnen kann — sondern darum, dass die Repositories, Issues und die Steuerebene, die sie hält, im Ausland leben und bei jedem Klon und Push die Grenze überqueren. Ein Seitenlade-Test beobachtet, wie der Anmeldebildschirm rendert; er kann nicht sehen, welcher Host den Code hält, welche personenbezogenen Daten in der Commit-Historie liegen oder dass Ihre gesamte Codebasis im Ausland konzentriert ist. |
| Ein selbst gehosteter Runner ist nicht die Steuerebene | Die DevOps-Falle. Ein selbst gehosteter Runner führt nur Jobs aus; der Quellcode, die Secrets, die Issue-Historie und die Steuerebene leben weiterhin dort, wo der Server läuft. Die Oberfläche erreichbar zu machen oder einen Runner im Inland zu platzieren, verschiebt keinen Code ins Inland. Die GitHub-Enterprise-Server-Instanz selbst im Festland zu betreiben, tut es. |
| Residenz & Grenztransfer | Repositories und Mitwirkenden-Daten offshore zu halten, ist ein grenzüberschreitender Transfer (数据出境) nach PIPL Art. 38–40, zusätzlich zur Mitteilung nach Art. 13/23 und der gesonderten Einwilligung für den Auslandstransfer. Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen verlangt Cybersicherheitsgesetz Art. 39 (vormals Art. 37), dass in China erhobene personenbezogene Daten im Festland gespeichert werden — was das Offshore-SaaS nicht erfüllen kann, eine selbst gehostete Inland-Instanz aber schon. |
| Erreichbarkeit ist nicht die Achse | Ob die Web-Oberfläche aus dem Festland schnell lädt, ist operativ, nicht die Compliance-Frage. Was entscheidet, ist, wo Code und personenbezogene Daten liegen und unter welcher Einwilligung. 21YunBox hilft Ihnen, diesen regulierten Inhalt auf Ihrer Inland-Instanz zu halten, die Transfergrundlage für alles abzusichern, was ausreist, jede auf China ausgerichtete Oberfläche per ICP zu melden und den Entwicklerzugang rechtskonform auszuliefern — der 21YunBox Optimizer — vor dem Server, den Sie bereits betreiben. Niemals eine Umgehung welcher Art auch immer. |
Was es tatsächlich hält — Ihr Quellcode, Secrets und Mitwirkenden-Identitäten
GitHub Enterprise Server ist keine öffentliche Marketing-Site; es ist das Zuhause Ihres konzentriertesten geistigen Eigentums und hält einen bemerkenswert vollständigen Datensatz darüber, wie Ihre Software gebaut wird. Jedes Repository ist der Quellcode Ihrer Produkte — Geschäftsgeheimnisse per Definition und in der Praxis oft mit in die Historie eingebetteten Anmeldedaten, API-Schlüsseln und Token. Um den Code herum sitzen die Issues, Pull-Request-Diskussionen, Code-Reviews und Wikis — eine laufende Karte dessen, was Sie bauen, und in Ihren Sicherheitsbefunden, wo Sie am schwächsten sind. Und die Instanz trägt die Identität aller, die mitgewirkt haben: Namen und E-Mail-Adressen, die an jedem Commit hängen, plus die Metadaten, wer was wann geändert hat. Wo diese Datensätze eine Person benennen oder beschreiben, sind sie personenbezogene Daten nach Chinas Gesetz zum Schutz personenbezogener Daten. Zusammengenommen ist eine GitHub-Enterprise-Server-Instanz ein konzentriertes Bild Ihrer Engineering-Organisation — und ob sie im Festland oder im Ausland lebt, wird davon entschieden, wo Sie den Server betreiben, denn GitHub Enterprise Server ist die selbst gehostete Edition, die Sie selbst in China platzieren können.
Die Türen: Residenz, Grenztransfer und die ICP-Oberfläche
Stellen Sie Ihre Instanz auf einen Offshore-Server — oder nehmen Sie das gehostete GitHub Enterprise Cloud, das keine Festland-China-Region bietet —, und die erste Tür öffnet sich. Die Repositories, die Commit-Historie und die Mitwirkenden-Identitäten ruhen im Ausland, was es zu einem grenzüberschreitenden Transfer (数据出境) macht. Die Pflicht trifft Sie, die Kundin, nicht GitHub: PIPL Art. 13 und 23 verlangen Mitteilung und eine Grundlage zur Erhebung der Daten, und Art. 38–40 verlangen einen Transfermechanismus, um sie offshore zu senden — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung — mit gesonderter Einwilligung für den Auslandstransfer.
Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen verlangt Art. 39 des Cybersicherheitsgesetzes (vormals Art. 37 — die Novelle des Cybersicherheitsgesetzes 2025, in Kraft seit 1. Januar 2026, hat den Artikel zur Datenlokalisierung von 37 auf 39 umnummeriert, inhaltlich unverändert), dass in China erzeugte personenbezogene Daten im Festland gespeichert werden. Das Offshore-SaaS hat keine China-Region und kann diese Pflicht nicht erfüllen; ein selbst gehostetes GitHub-Enterprise-Server-Deployment, im Festland platziert, kann es, weshalb die China-Antwort hier warn ist, nicht no.
Und in dem Moment, in dem Sie eine öffentliche, auf China ausgerichtete Oberfläche mit der Instanz verbinden — ein extern bereitgestelltes Entwicklerportal, eine Dokumentations- oder Releases-Seite, eine Statusseite, die Festland-Nutzern bereitgestellt wird —, ist diese Oberfläche ein Internet-Informationsdienst und trägt eine ICP-Beian-Pflicht (备案), die an eine Festland-Hosting-Ressource gebunden ist. Eine rein interne GitHub-Enterprise-Server-Instanz löst ICP womöglich nicht von allein aus; eine öffentliche, Nutzern in China bereitgestellte Oberfläche schon.
Ein selbst gehosteter Runner ist nicht die Steuerebene
Es ist verlockend zu denken, dass ein selbst gehosteter Runner in China die Residenzfrage beantwortet. Das tut er nicht. Ein Runner führt nur Jobs aus; der Quellcode, die Secrets, die Issue-Historie und die Steuerebene, die sie indexiert, leben alle weiterhin dort, wo die GitHub-Enterprise-Server-Instanz läuft. Die Web-Oberfläche aus dem Festland erreichbar zu machen oder einen Runner dort zu stationieren, verschiebt keinen Code ins Inland — es verschiebt nur, wo ein Build zufällig läuft. Die Residenzfrage wird davon beantwortet, wo der Server und seine Steuerebene sitzen, nicht von Erreichbarkeit und nicht von einem Runner. Die GitHub-Enterprise-Server-Instanz selbst im Festland zu betreiben, hält die Repositories, die Metadaten und die Mitwirkenden-Daten resident.
Warum eine Erreichbarkeitsprüfung das verfehlt
Eine Sonde aus China kann beobachten, wie der GitHub-Enterprise-Server-Anmeldebildschirm rendert, und daraus schließen „es funktioniert“. Diese Antwort geht am Kern vorbei. Die Compliance-Exponierung steht nicht auf dem Bildschirm — sie liegt in den ruhenden Daten und darin, wie sie sich bewegen: die Repositories, die Commit-Historie mit ihren eingebetteten Secrets, die Issues und die Mitwirkenden-Identitäten, allesamt auf einem Server und, ist dieser Server offshore, bei jedem Klon und Push über der Grenze. Ein Seitenlade-Test misst nichts davon. Er kann nicht sehen, welcher Host den Code hält, ob gesonderte Einwilligung eingeholt wurde, ob ein Transfermechanismus besteht oder dass Ihre gesamte Codebasis im Ausland konzentriert ist. Das ist die konkurrenzsichere zweite Hälfte der Frage — und genau deshalb ist es nicht die Antwort, einen Offshore-Server lediglich aus dem Festland erreichbar zu machen. Die selbst gehostete Edition im Inland zu betreiben und Code und personenbezogene Daten dort zu halten, ist es.
Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern
Es gibt einen rechtskonformen Weg, GitHub Enterprise Server für einen Festlandchina-Betrieb zu führen, und er sitzt vor der Instanz, die Sie bereits betreiben — kein Neuaufbau, keine Migration und niemals ein Weg, der Daten heimlich ins Ausland schafft.
Zuerst kartieren: Unser China-Compliance-Team inventarisiert, was Ihre Instanz hält — die Repositories, die in die Historie eingebetteten Secrets, die Issues und Pull-Request-Diskussionen, die Mitwirkenden-Identitäten —, stellt fest, wo der Server und seine Steuerebene laufen und auf welcher Residenzgrundlage, den ICP-Status jeder auf China ausgerichteten Oberfläche und ob Ihr konzentrierter Code und Ihre personenbezogenen Daten Inland-Speicherpflichten berühren. Wir bauen das technische Bild; die rechtlichen Schlüsse werden mit Rechtsbeistand geklärt.
Dann lokalisieren: Weil GitHub Enterprise Server selbst hostbar ist, ist Lokalisieren eine echte Option — die selbst verwaltete Instanz auf Inland-Infrastruktur betreiben, sodass Code, Issues, Secrets und Steuerebene im Festland bleiben, die in Commits und Issues getragenen personenbezogenen Daten minimieren, die Steuerebene steuern und die Mitteilung nach Art. 13/23 und die gesonderte Einwilligung für alles einholen, was noch die Grenze überquert. Lokalisieren bedeutet, die Daten auf einem Inland-Pfad zu halten — niemals ein Weg welcher Art auch immer, der sie offshore schafft oder über die Grenze zurückgreift, um sie abzurufen.
Dann ausliefern: Jede öffentliche, auf China ausgerichtete Oberfläche ist ein Internet-Informationsdienst, trägt also eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung, und Ihre Entwickler brauchen schnellen, verlässlichen Zugang zur Instanz aus dem Festland. 21YunBox liefert das im Inland aus — der 21YunBox Optimizer — vor dem GitHub Enterprise Server, den Sie bereits betreiben, sodass der Entwicklerzugang und jede auf China ausgerichtete Oberfläche für Ihre Nutzer in China rechtmäßig und rechtskonform laufen. 21YunBox verwendet oder empfiehlt niemals eine Umgehung welcher Art auch immer — wir halten im Inland, was das Gesetz dort verlangt, liefern den Rest rechtskonform aus dem Festland aus und bewegen personenbezogene Daten niemals heimlich über die Grenze. 21YunBox ist eine Compliance-Overlay und Partnerin der Plattform, die Sie bereits betreiben, keine Konkurrentin.
Nichts davon ist ein Urteil, dass GitHub Enterprise Server in China „gesperrt“ oder „illegal“ sei; es ist eine Risiko- und Residenzkarte. Welche Pflichten Ihren Fall treffen, hängt von Ihrer Rechtsperson, Ihrer Rolle nach chinesischem Recht, Ihren Datenmengen und davon ab, was Ihre Instanz tatsächlich hält — klären Sie die Einzelheiten mit Rechtsbeistand, bevor die gesamte Codebasis Ihrer Organisation davon abhängt.
Compliance-Einschätzung anfordern →
Weiterführend:
- So erhalten Sie eine ICP-Beian für China
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Gesetz zum Schutz personenbezogener Daten (PIPL)
- Chinas Cybersicherheitsgesetz (Datenlokalisierung, Art. 39)
Häufige Fragen
Ist GitHub Enterprise Server dasselbe wie GitHub.com oder GitHub Enterprise Cloud?
Nein. GitHub Enterprise Server ist die selbst hostbare, selbst verwaltete Edition, die Sie auf Ihrer eigenen Infrastruktur betreiben — GitHubs Dokumentation nennt es „eine selbst gehostete Version der GitHub-Plattform“, bereitstellbar auf einem On-Premises-Hypervisor oder Ihrer eigenen Cloud. GitHub.com und GitHub Enterprise Cloud sind das gehostete SaaS, und die Datenresidenz von GitHub Enterprise Cloud listet nur EU, Australien, USA und Japan — keine Festland-China-Region. Der Unterschied ist für China der ganze Punkt: Der selbst gehostete Server kann im Festland platziert werden, sodass der Code resident bleibt, während das SaaS das nicht kann.
Können wir GitHub Enterprise Server auf unseren eigenen Servern in Festlandchina betreiben?
Ja — das ist der Sinn seines selbst verwalteten Modells. GitHub gibt an, dass Sie „GitHub Enterprise Server auf einem Virtualisierungs-Hypervisor im eigenen Rechenzentrum oder auf einem Public-Cloud-Dienst bereitstellen“ können, ein Festland-Deployment ist also möglich, und es ist genau das, was Ihnen erlaubt, Repositories, Issues, Secrets und die Steuerebene im Festland zu halten. Was Selbst-Hosting von allein nicht tut, ist, eine ICP-Beian für eine öffentliche auf China ausgerichtete Oberfläche zu gewähren, PIPL-Einwilligungen abzusichern oder die Grenztransfer-Regeln für alles zu erfüllen, was das Festland verlässt — das bleiben Pflichten des Betreibers, zu klären mit Rechtsbeistand.
Wir haben einen selbst gehosteten Runner in China platziert — macht das es rechtskonform?
Nein. Ein selbst gehosteter Runner führt nur Jobs aus; der Quellcode, die Secrets, die Issue-Historie und die Steuerebene leben weiterhin dort, wo die GitHub-Enterprise-Server-Instanz läuft. Die UI erreichbar zu machen oder einen Runner im Inland zu stationieren, verschiebt keinen Code ins Inland — es ändert nur, wo ein Build zufällig läuft. Die Residenzfrage wird davon beantwortet, wo der Server und seine Steuerebene sitzen. Die GitHub-Enterprise-Server-Instanz selbst im Festland zu betreiben, hält den Code und die Mitwirkenden-Daten resident.
