Am 24. April 2026 änderte sich die Modelltrainings-Richtlinie von GitHub für individuelle Copilot-Pläne. GitHub darf nun Interaktionen aus Copilot Free, Pro, Pro+ und Max verwenden, einschließlich Eingaben, Ausgaben, Code-Snippets und zugehörigem Kontext, um KI-Modelle zu trainieren und zu verbessern, sofern der Nutzer nicht widerspricht. Daten aus Copilot Business und Enterprise bleiben durch die Datenschutzvereinbarung von GitHub geschützt. Entscheidend: Es geht um Copilot-Interaktionsdaten, nicht um private Repositories, die ungenutzt auf GitHub liegen.
Gleichzeitig kamen Migrationsargumente aus einem anderen Grund wieder auf: Öffentliche selbstgehostete Git-Instanzen absorbierten starken automatisierten Traffic. Eine Diskussion auf Hacker News sammelte eine nützliche Reihe von Betreiberberichten zu diesem Problem: Ende einer Ära für mich: kein selbstgehostetes git mehr.
Damit bleibt eine nützlichere Frage als „GitHub oder Self-Hosting?“: Welches Problem wollen Sie eigentlich lösen?
Die Kurzfassung
Drei Antworten. Wählen Sie die, die zu Ihrer Situation passt.
- A: Widersprechen und bleiben. Nutzen Sie das, wenn die Copilot-Trainingsänderung Ihre einzige Sorge ist und GitHub weiterhin zum Betrieb Ihres Teams passt. Deaktivieren Sie die Einstellung auf Kontoebene und machen Sie weiter.
- B: Hybrid fahren. Öffentliche Open-Source-Projekte bleiben wegen des Netzwerkeffekts auf GitHub. Privaten Code verschieben Sie auf eine selbstgehostete Forgejo-, Gitea- oder GitLab-CE-Instanz hinter einem VPN oder einer IP-Allowlist. Nutzen Sie das, wenn öffentliche Reichweite und private Kontrolle gleichzeitig zählen.
- C: Vollständig migrieren. Ziehen Sie alles von GitHub ab. Nutzen Sie das, wenn Regulierung, Datenresidenz, Governance oder eine reine FOSS-Richtlinie GitHub ausschließen und das Team die Betriebskosten tragen kann.
Die meisten Leser stehen bei Position A oder B. Position C rechtfertigt sich durch strengere Anforderungen an Governance, Souveränität oder Werte, nicht durch die Copilot-Einstellung allein.
Was sich im April 2026 tatsächlich geändert hat
Die technische Änderung ist klein. In den Copilot-Einstellungen können Einzelabonnenten „Allow GitHub to use my data for AI model training“ auf Disabled setzen. GitHub beschreibt das erfasste Material als Interaktionen mit seinen Funktionen und Diensten, einschließlich Eingaben, Ausgaben, Code-Snippets und zugehörigem Kontext, nicht als Inhalte privater Repositories, die nie durch Copilot gelaufen sind.
Copilot Business und Enterprise zeigen diesen Schalter nicht, weil ihre Daten durch die Datenschutzvereinbarung von GitHub geschützt sind. Bei individuellen Plänen beantwortet das Deaktivieren die Frage der Trainingsrichtlinie; es löst nicht den grundsätzlicheren Einwand, von einer anbieterkontrollierten Richtlinie abzuhängen.
Die Copilot-Änderung kann der Auslöser sein, ohne die ganze Begründung zu liefern. Ein Team kann sich außerdem um Plattformabhängigkeit sorgen, um die an GitHub gebundene Identität, um Workflows rund um Actions, um Datenresidenz oder darum, wie leicht ein weiterer Umzug später wäre. Das sind Migrationsfragen; der Trainingsschalter ist nur eine Einstellung.
Diese Unterscheidung zählt: Ein Widerspruch ändert eine Einstellung zur Datennutzung, eine Migration ändert, wer Hosting, Identität, Integrationen und Richtlinien kontrolliert. Die zweite Entscheidung kostet im Betrieb weit mehr.
Die drei Positionen im Detail
Die Entscheidung, komprimiert auf drei Zeilen. Details weiter unten.
| Ihr Anliegen | Antwort | Was zu tun ist |
|---|---|---|
| Meine Copilot-Interaktionsdaten werden fürs Training genutzt | Widersprechen und bleiben (Position A) | Schalter umlegen, weiterarbeiten |
| Privater Code, den ich nicht bei einem US-Anbieter haben will, + aktive Open-Source-Projekte, die ich nicht verstecken will | Hybrid (Position B) | Private Repositories selbst hosten, hinter einem VPN; öffentliche Open-Source-Projekte auf GitHub lassen |
| Souveränität, regulierte Branche, prinzipielles Nur-FOSS, vollständige Anbieterunabhängigkeit | Vollständige Migration (Position C) | Alles umziehen; Betriebskosten einplanen |
Position A: Widersprechen und bleiben
Wenn Sie Einzelentwickler oder ein kleines Team mit privaten Repos sind und Ihre einzige Kritik der Trainings-Standard ist, ist das Ihre Antwort. Einen Schalter umlegen: eine Minute, einmal. Selbst hosten: eine kleine VPS-Rechnung, eine Backup-Strategie, die Sie wirklich testen, Integrationen, die Sie neu bauen, weil sie GitHub-Auth voraussetzten, und das gelegentliche Upgrade oder Recovery, das zum denkbar schlechtesten Zeitpunkt kommt.
Selbst hosten kann sich trotzdem lohnen, aber nur, wenn diese wiederkehrende Arbeit Ihnen etwas einbringt, das Sie wirklich brauchen.
Der stärkste Einwand: Der Schalter ist ebenfalls eine Anbieterentscheidung. GitHub ist 2026 davon, diese Interaktionsdaten standardmäßig nicht fürs Training zu nutzen, dazu übergegangen, sie standardmäßig zu nutzen, und könnte die Richtlinie erneut ändern.
Wenn Ihr eigentliches Anliegen lautet „Ich will nie, dass ein US-Anbieter einseitig über meinen Code entscheidet“, löst das kein Häkchen, und Position A ist für Sie die falsche Antwort. Springen Sie zu Position C.
Wenn Ihr Anliegen aber konkret lautet „Ich will meine aktuellen Copilot-Interaktionsdaten nicht im Training haben“ und Sie der Einstellung von GitHub bis zur nächsten Änderung vertrauen, ist Position A die billigste richtige Antwort. Billig und richtig ist nichts, wofür man sich schämen müsste.
Position B: Ein Hybridmodell fahren
Hybrides Hosting trennt öffentliche Reichweite von privater Kontrolle.
Die Aufteilung ist einfach. Öffentliche Open-Source-Projekte bleiben auf GitHub: Netzwerkeffekt, Zulauf an Mitwirkenden, Dependabot und das Actions-Ökosystem sind echter Wert. Privater Code zieht auf eine selbstgehostete Instanz hinter einem VPN oder einer IP-Allowlist um, aus dem öffentlichen Internet nie erreichbar.
Dass das funktioniert, ist eine Eigenschaft des Bedrohungsmodells. Die Copilot-Trainingsfrage betrifft nur Copilot-Interaktionsdaten, die Sie über GitHub senden. Das Problem des KI-Scraper-Traffics (nächster Abschnitt) betrifft nur öffentlich erreichbare Instanzen. Ein privates Hybrid-Setup umgeht beides.
Für ein privates Team von 2 bis 10 Personen sind 2 vCPU und 4 GB RAM ein sichererer Startpunkt für Forgejo oder Gitea, mit mehr Luft, falls Suchindizierung, Pakete oder CI denselben Host teilen. Betrachten Sie das als Forgejo/Gitea-Dimensionierung, nicht als GitLab-CE-Dimensionierung: das Single-Node-Tutorial von GitLab beginnt bei 8 vCPU und 7,2 GB Arbeitsspeicher, noch ohne CI-Last.
Stellen Sie die Web-Oberfläche nicht offen auf 80 oder 443 bereit. Schränken Sie sie auf Firewall-, Proxy-, VPN- oder Mesh-Netzwerk-Ebene ein. CI-Runner können beide Seiten bedienen.
Die Plattformwahl verändert den Funktionsumfang stärker als das Hybridmodell selbst. Forgejo und Gitea passen zu einer leichteren privaten Forge; GitLab CE ergibt mehr Sinn, wenn Sie zusätzlich einen integrierten CI/CD- und Registry-Stack brauchen.
Backups sind machbar, aber reduzieren Sie sie nicht auf ein git bundle. Die offizielle Upgrade-Anleitung von Forgejo betrachtet einen synchronisierten Point-in-Time-Snapshot des gesamten von Forgejo genutzten Speichers als zuverlässiges Backup und, wo das nicht praktikabel ist, einen Forgejo-Dump zusammen mit einem separaten PostgreSQL- oder MySQL-Dump. Halten Sie für Forgejo wie für Gitea Repositories, Datenbank, Konfiguration, Anhänge und LFS-Daten zusammen, lagern Sie eine Kopie außerhalb des Servers, und testen Sie eine Wiederherstellung.
Der lokale Klon eines Entwicklers kann Code wiederherstellen, aber keine Issues, Nutzer, Pull-Request-Metadaten, Anhänge oder alle LFS-Objekte. Wird ein privater Fork später öffentlich, pushen Sie ihn zu diesem Zeitpunkt in einen GitHub-Mirror.
Position C: Vollständige Migration, wenn Kontrolle eine Anforderung ist
Die vollständige Migration passt am klarsten, wenn Anbieterunabhängigkeit eine Anforderung und keine Vorliebe ist.
Drei Gruppen stechen hervor: regulierte Teams mit Audit-, Residenz- oder Anbieterkontrollregeln, die GitHub ausschließen; Teams aus dem öffentlichen Sektor oder der EU, deren Souveränitätsanforderungen Vorschrift und nicht Vorliebe sind; und reine FOSS-Organisationen, die von Microsoft-eigener Infrastruktur weg wollen und bereits Personal haben, das Linux-Dienste betreiben kann.
Die Kosten sind ein kleiner VPS, laufende Wartung und der Verlust von Integrationen. Den Integrationsverlust vergisst man am ehesten. Alles, was sich per „Sign in with GitHub“ authentifiziert, bleibt auf GitHub oder braucht einen eigenen Identitätsanbieter.
Planen Sie die Migration um Abhängigkeiten herum, nicht nur um Repositories. PR-Previews, Actions von Drittanbietern, Bots, Webhooks, Paketregistries und „Sign in with GitHub“-Integrationen brauchen womöglich neue Zugangsdaten, neue Workflows oder Ersatzdienste. Sterne und Watcher werden auf der neuen Forge nicht zu nativen Einträgen, öffentliche Projekte geben also auch einen Teil ihres bestehenden Auffindbarkeitssignals auf.
Machen Sie einen Testlauf, bevor Sie das kanonische Remote umstellen: migrieren Sie ein repräsentatives Repository, bauen Sie dessen Integrationen neu auf, prüfen Sie Issue- und Pull-Request-Historie, und dokumentieren Sie den Rollback-Weg. Der Plattformvergleich kommt nach diesem Abhängigkeitsaudit.
Für Teams, die gemeinnützige Governance ohne eigenen Serverbetrieb wollen, ist Codeberg eine Überlegung wert.
Praxistipp zur Souveränität. Wenn Sie sich wegen EU-Datenresidenz für Self-Hosting entscheiden, zählt der Standort des Rechenzentrums. Orte wie Frankfurt oder Amsterdam sind die langweilige, aber richtige Wahl. Der billigste VPS in Virginia hilft Ihrem AV-Vertrag nicht.
Die Betriebskosten von öffentlichem Git-Hosting
Öffentliches Self-Hosting setzt eine Forge demselben automatisierten Traffic aus, der jede aus dem Internet erreichbare Anwendung trifft, nur enthalten Repository-Seiten teure Pfade wie Blame-Ansichten, Archive und Commit-Historie. Die folgenden Berichte sind individuelle Betreibererfahrungen, keine Benchmarks.
In der oben erwähnten Diskussion über selbstgehostetes Git berichtete ein Betreiber von 37.212.377 Anfragen gegen eine cgit-Instanz in 60 Tagen, von denen über 99 % als Bots eingestuft wurden.
In derselben Diskussion berichtet kstrauser, eine Forgejo-Instanz von rund 600.000 Anfragen pro Tag auf etwa 1.000 gebracht zu haben, allerdings erst nach einer JavaScript-und-Cookie-Challenge zusätzlich zu den üblichen Maßnahmen.
Andere Betreiber nannten fail2ban, GeoIP-Sperren, Blackholes auf Ebene autonomer Systeme und das Zurückverlagern von Repositories auf gehostete Plattformen. Diese Berichte zeigen mögliche Fehlerbilder; sie sind keine allgemeingültigen Traffic-Referenzwerte.
Der technische Grund, warum das schwierig ist: einfaches Rate-Limiting pro IP kann an Traffic scheitern, der über wechselnde Residential-Proxys läuft. Eine Scraper-Flotte kann Anfragen auf so viele IPs verteilen, dass keine einzelne Adresse auffällig wirkt, während der Server in Summe trotzdem überlastet wird.
JavaScript- oder Cookie-Challenges können unraffiniertes Scraping verringern, aber sie können auch Nutzer ohne JavaScript aussperren und Git over HTTPS stören, wenn man sie auf jeden Pfad anwendet. CDN-Caching hilft bei wiederholten Lesezugriffen; bei einzigartigen oder teuren Endpunkten wie Archiven, Blame-Ansichten und Seiten pro Commit hilft es deutlich weniger.
Was eine Challenge verändert, ist die Ökonomie. Anubis setzt sich vor eine Forge und lässt einen Client eine Challenge lösen, etwa eine kleine Proof-of-Work-Berechnung, bevor der Server die geschützte Seite ausliefert, was massenhaftes Crawlen teurer macht. Das ist Schadensbegrenzung, keine Garantie.
Setzen Sie Browser-Challenges gezielt ein. Halten Sie SSH für Git-Operationen offen, und testen Sie Git over HTTPS, bevor Sie diesen Pfad schützen: Eine Challenge-Seite, die an einen Git-Client geht, wird zu einem fehlgeschlagenen Klon, nicht zu einer nützlichen Prüfung.
GitHub fängt diese Traffic-Klasse als Teil seines gehosteten Dienstes ab. Eine öffentliche Forgejo- oder cgit-Instanz überlässt Ihnen Kapazitätsplanung, Missbrauchskontrollen, Caching und Gegenmaßnahmen. Diese Verlagerung des Betriebs, nicht die reinen Softwarekosten, ist der wichtige Teil der Migrationsentscheidung.
Genau deshalb ist das Hybridmodell eine erstklassige Option und kein Notnagel. Privater Code hinter einem VPN: Scraper kommen nicht heran. Öffentliche Open-Source-Projekte auf GitHub: Die Anti-Missbrauchs-Infrastruktur von GitHub übernimmt den Bot-Traffic.
Wenn Sie trotzdem eine öffentliche selbstgehostete Forge wollen, planen Sie Budget ein für Logs, Rate-Kontrollen, Caching, Bot-Abwehr, Monitoring und einen getesteten Pfad für Git-Traffic, der nicht von Browser-Challenges abhängt. Behandeln Sie Scraper-Abwehr als Teil des Normalbetriebs, nicht als Sonderfall.
Die Netzwerkeffekt-Frage für Open-Source-Maintainer
Ich spreche hier einen ganz bestimmten Leser an: Sie betreuen ein Open-Source-Projekt. Zwanzig Mitwirkende, zweihundert Sterne und ein aktiver Issue-Tracker. Sie überlegen, es von GitHub wegzuholen.
Seien Sie ehrlich, was Sie eintauschen: Auffindbarkeit für Mitwirkende, das implizite Vertrauenssiegel von github.com, Dependabot, CodeQL und das Drittanbieter-Ökosystem, das auf GitHub-Auth aufsetzt. Nichts davon ist anderswo unmöglich; alles wird zu Reibung.
Die Faustregel, die ich anbieten würde: Wenn der Wert Ihres Projekts vor allem im Code steckt, lässt sich Self-Hosting leichter rechtfertigen.
Code lässt sich mitnehmen. Hängt sein Wert aber stark an Mitwirkenden, Issues, Sichtbarkeit in der Suche und dem Vertrauen rund um github.com, dann tauscht ein Weggang einen Teil dessen ein, was das Projekt funktionieren lässt, gegen das, was dem Maintainer ein besseres Gefühl gibt. Ein legitimer Tausch, wenn Ihre Gründe groß genug sind. Ein schlechter Tausch, wenn Sie damit nur ein Zeichen setzen wollen.
Die Plattformübersicht von Codeberg beschreibt einen Forgejo-basierten Dienst, betrieben vom gemeinnützigen Codeberg e.V. Für Open-Source-Maintainer bedeutet das Community-Governance ohne den Wartungsaufwand, die Forge selbst zu betreiben.
Für Open-Source-nahe Teams, die Community-Governance ohne Update-Pflicht wollen, ist das ein kleinerer operativer Sprung als der Betrieb einer öffentlichen Forge. SourceHut bedeutet eine deutlich bewusstere Änderung des Workflows und braucht eine eigene Bewertung.
Machen Sie die kleinste Änderung, die das Problem löst
Bevor Sie Remotes umstellen, schreiben Sie die Anforderung in einem Satz auf: Training auf Copilot-Interaktionsdaten stoppen, öffentliches und privates Hosting trennen, oder GitHub aus der Architektur entfernen. Wenn Sie die Anforderung nicht benennen können, migrieren Sie noch nicht.
Starten Sie eine Migration mit einem repräsentativen Pilot-Repository. Inventarisieren Sie Authentifizierung, Actions, Webhooks, Paketveröffentlichung, Preview-Umgebungen, Issue-Historie, LFS-Daten und Rollback-Schritte, bevor Sie das kanonische Remote umstellen.
Cloudzys Forgejo-Bereitstellung mit einem Klick ist ein schneller Weg, die private Seite eines Hybridmodells aufzusetzen; eine manuelle Installation auf einem beliebigen Linux VPS funktioniert ebenfalls. Welchen Weg Sie auch wählen: Halten Sie die Web-Oberfläche privat, sichern Sie den vollständigen Anwendungszustand, und testen Sie die Wiederherstellung, bevor Sie ein kritisches Repository umziehen.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenKontrolle nützt nur, wenn sie die Anforderung erfüllt, zu Betriebskosten, die Ihr Team dauerhaft tragen kann.
Häufig gestellte Fragen
Sollte ich wegen der Copilot-Trainingsänderung von GitHub weg migrieren?
Nicht automatisch. Wenn Ihre einzige Sorge ist, dass Copilot-Interaktionsdaten fürs Modelltraining genutzt werden, ist das Deaktivieren der Einstellung auf Kontoebene die kleinste richtige Lösung. Eine Migration ergibt Sinn, wenn Sie zusätzlich strengere Kontrollen bei Datenresidenz, Governance, Anbieterunabhängigkeit oder einer reinen FOSS-Politik brauchen.
Trainiert GitHub auf allen meinen privaten Repositories?
Nein. Die hier besprochene Richtlinienänderung erfasst die betroffenen Copilot-Interaktionsdaten, einschließlich Eingaben, Ausgaben, Code-Snippets und zugehörigem Kontext, die durch Copilot gesendet wurden. Sie bedeutet nicht, dass jedes auf GitHub gespeicherte private Repository automatisch fürs Modelltraining genutzt wird.
Ist selbstgehostetes Git immer privater?
Nur wenn Sie es so betreiben. Eine private Forge hinter einem VPN oder einer IP-Allowlist kann die Angriffsfläche verringern, aber eine öffentlich erreichbare Instanz bringt Verantwortung für Patches, Monitoring, Bot-Abwehr, Zugriffskontrolle und Backups mit sich, die GitHub sonst übernimmt.
Welche selbstgehostete Git-Plattform sollte ich wählen?
Wählen Sie Forgejo oder Gitea, wenn Sie eine leichtere private Forge wollen. Wählen Sie GitLab CE, wenn integriertes CI/CD und eine Paket- oder Container-Registry wichtig genug sind, um den höheren Ressourcen- und Wartungsbedarf zu rechtfertigen.
Welche VPS-Größe brauchen Forgejo oder Gitea für ein kleines Team?
Für ein privates Team von zwei bis zehn Personen sind 2 vCPU und 4 GB RAM ein sichererer Startpunkt. Legen Sie Kapazität nach, wenn Suchindizierung, Pakete, große Repositories oder CI-Runner denselben Host teilen. GitLab CE dimensionieren Sie separat, denn es braucht mehr Ressourcen.
Was sollte ich testen, bevor ich das kanonische Remote umstelle?
Machen Sie einen Piloten mit einem repräsentativen Repository. Prüfen Sie Issue- und Pull-Request-Historie, Authentifizierung, Actions oder Ersatz-CI-Workflows, Webhooks, Paketveröffentlichung, LFS-Daten, Preview-Umgebungen, Backups, Wiederherstellung und den Rollback-Weg, bevor Sie alles umziehen.
