Op 24 april 2026 veranderde het modeltrainingsbeleid van GitHub voor individuele Copilot-abonnementen. GitHub mag nu interacties uit Copilot Free, Pro, Pro+ en Max gebruiken, inclusief invoer, uitvoer, codefragmenten en bijbehorende context, om AI-modellen te trainen en te verbeteren, tenzij de gebruiker zich afmeldt. Gegevens van Copilot Business en Enterprise blijven beschermd onder de gegevensbeschermingsovereenkomst van GitHub. Cruciaal: dit gaat over Copilot-interactiegegevens, niet over privérepositories die ongebruikt op GitHub staan.
Tegelijk kwamen migratieargumenten om een andere reden weer op: publieke zelfgehoste Git-instanties vingen zwaar geautomatiseerd verkeer op. Een discussie op Hacker News verzamelde een nuttige reeks beheerdersverslagen over dat probleem: Einde van een tijdperk voor mij: geen zelfgehoste git meer.
Dat laat een nuttiger vraag over dan "GitHub of zelf hosten?": welk probleem probeer je eigenlijk op te lossen?
De korte versie
Drie antwoorden. Kies degene die bij jouw situatie past.
- A: Afmelden en blijven. Kies dit als de Copilot-trainingswijziging je enige zorg is en GitHub nog steeds past bij de operationele behoeften van je team. Zet de instelling op accountniveau uit en ga verder.
- B: Draai een hybride opzet. Houd publieke OSS op GitHub voor het netwerkeffect. Verplaats privécode naar een zelfgehoste Forgejo-, Gitea- of GitLab CE-instantie achter een VPN of IP-allowlist. Kies dit als publiek bereik en privécontrole tegelijk tellen.
- C: Volledig migreren. Haal alles weg bij GitHub. Kies dit als regelgeving, dataresidentie, governance of een uitsluitend-FOSS-beleid GitHub uitsluit en het team de exploitatiekosten aankan.
De meeste lezers zitten in positie A of B. Positie C wordt gerechtvaardigd door strengere eisen rond governance, soevereiniteit of waarden, niet door de Copilot-instelling alleen.
Wat er in april 2026 echt veranderde
De technische wijziging is klein. In de Copilot-instellingen kunnen individuele abonnees "Allow GitHub to use my data for AI model training" op Disabled zetten. GitHub omschrijft het betrokken materiaal als interacties met zijn functies en diensten, inclusief invoer, uitvoer, codefragmenten en bijbehorende context, niet als de inhoud van privérepositories die nooit door Copilot is gegaan.
Copilot Business en Enterprise tonen deze schakelaar niet, omdat hun gegevens beschermd zijn door de gegevensbeschermingsovereenkomst van GitHub. Bij individuele abonnementen pakt het uitzetten van de instelling de zorg over het trainingsbeleid aan; het lost niet het bredere bezwaar op dat je afhankelijk bent van beleid dat de leverancier bepaalt.
De Copilot-wijziging kan de aanleiding zijn zonder het hele verhaal te zijn. Een team kan ook geven om platformafhankelijkheid, identiteit die aan GitHub vastzit, workflows rond Actions, dataresidentie, of hoe makkelijk het later opnieuw kan verhuizen. Dat zijn migratievragen; de trainingsschakelaar is maar één instelling.
Dat onderscheid telt: afmelden verandert één instelling voor datagebruik, terwijl migreren verandert wie de hosting, identiteit, integraties en het beleid bepaalt. De tweede beslissing kost operationeel veel meer.
De drie posities uitgelegd
De beslissing samengevat in drie rijen. Details hieronder.
| Jouw zorg | Antwoord | Wat te doen |
|---|---|---|
| Mijn Copilot-interactiegegevens worden gebruikt voor training | Afmelden en blijven (positie A) | Zet de instelling om en ga weer aan het werk |
| Privécode die ik niet bij een Amerikaanse aanbieder wil + actieve open source die ik niet wil verbergen | Hybride (positie B) | Host privérepositories zelf achter een VPN; houd publieke open source op GitHub |
| Soevereiniteit, gereguleerde sector, principieel alleen vrije software, volledige leveranciersonafhankelijkheid | Volledige migratie (positie C) | Verplaats alles; begroot de exploitatiekosten |
Positie A: afmelden en blijven
Ben je een soloontwikkelaar of klein team met privérepo's en is je enige klacht de standaardinstelling voor training, dan is dit je antwoord. Een instelling omzetten: één minuut, eenmalig. Zelf hosten: een kleine VPS-rekening, een back-upstrategie die je echt test, integraties die je opnieuw moet bouwen omdat ze uitgingen van GitHub-auth, en de incidentele upgrade of herstelklus die op het slechtst denkbare moment valt.
Zelf hosten kan nog steeds de moeite waard zijn, maar alleen als dat terugkerende werk je iets oplevert dat je echt nodig hebt.
Het sterkste tegenargument: die schakelaar is óók een beslissing van de leverancier. GitHub ging in 2026 van deze interactiegegevens standaard niet gebruiken voor training naar ze standaard wél gebruiken, en kan het beleid opnieuw wijzigen.
Is je onderliggende zorg "ik wil nooit dat een Amerikaanse leverancier eenzijdig beslissingen neemt over mijn code", dan lost geen enkel vinkje dat op, en is positie A het verkeerde antwoord voor jou. Ga door naar positie C.
Maar is je zorg specifiek "ik wil mijn huidige Copilot-interactiegegevens niet in de training" en vertrouw je op de instelling van GitHub tot het volgende verandert, dan is positie A het goedkoopste juiste antwoord. Goedkoop en juist is niets om je voor te schamen.
Positie B: een hybride model draaien
Hybride hosting scheidt publiek bereik van privécontrole.
De verdeling is simpel. Publieke open source blijft op GitHub: netwerkeffect, aanwas van bijdragers, Dependabot en het Actions-ecosysteem zijn echte waarde. Privécode verhuist naar een zelfgehoste instantie achter een VPN of IP-allowlist, nooit bereikbaar vanaf het publieke internet.
Dat dit werkt, is een eigenschap van het dreigingsmodel. De zorg over Copilot-training geldt alleen voor Copilot-interactiegegevens die je via GitHub verstuurt. Het probleem van AI-scraperverkeer (volgende sectie) geldt alleen voor publiek bereikbare instanties. Een private hybride opzet ontwijkt allebei.
Voor een privéteam van 2 tot 10 personen zijn 2 vCPU en 4 GB RAM een veiliger startpunt voor Forgejo of Gitea, met meer ruimte als zoekindexering, packages of CI dezelfde host delen. Beschouw dat als Forgejo/Gitea-sizing, niet als GitLab CE-sizing: de single-node-tutorial van GitLab begint bij 8 vCPU en 7,2 GB geheugen, nog zonder CI-belasting.
Zet de webinterface niet open op 80 of 443. Beperk hem op firewall-, proxy-, VPN- of meshnetwerkniveau. CI-runners kunnen beide kanten bedienen.
De platformkeuze verandert het functiepakket meer dan het hybride model zelf. Forgejo en Gitea passen bij een lichtere private forge; GitLab CE is logischer als je ook een geïntegreerde CI/CD- en registrystack nodig hebt.
Back-ups zijn te doen, maar reduceer ze niet tot een git bundle. De officiële upgradehandleiding van Forgejo beschouwt een gesynchroniseerde point-in-time snapshot van alle opslag die Forgejo gebruikt als de betrouwbare back-up, en waar dat niet praktisch is, een Forgejo-dump samen met een aparte PostgreSQL- of MySQL-dump. Houd voor zowel Forgejo als Gitea repositories, database, configuratie, bijlagen en LFS-data bij elkaar, bewaar een kopie buiten de server, en test een herstel.
De lokale kloon van een ontwikkelaar kan code terughalen, maar geen issues, gebruikers, pull-requestmetadata, bijlagen of alle LFS-objecten. Wordt een privéfork later openbaar, push hem dan op dat moment naar een GitHub-mirror.
Positie C: volledige migratie als controle een vereiste is
Volledige migratie past het duidelijkst wanneer leveranciersonafhankelijkheid een vereiste is en geen voorkeur.
Drie groepen springen eruit: gereguleerde teams met audit-, residentie- of leverancierscontroleregels die GitHub uitsluiten; publieke of EU-teams voor wie soevereiniteitseisen beleid zijn en geen voorkeur; en uitsluitend-FOSS-organisaties die weg willen van infrastructuur in handen van Microsoft en al mensen hebben die Linux-diensten kunnen draaien.
De kosten zijn een kleine VPS, doorlopend onderhoud en verlies van integraties. Dat verlies van integraties is het stuk dat mensen vergeten. Alles wat inlogt met "Sign in with GitHub" blijft op GitHub of heeft een aparte identity provider nodig.
Plan de migratie rond afhankelijkheden, niet alleen rond repositories. PR-previews, Actions van derden, bots, webhooks, packageregistries en "Sign in with GitHub"-integraties hebben mogelijk nieuwe credentials, nieuwe workflows of vervangende diensten nodig. Sterren en watchers worden op de nieuwe forge geen native records, dus publieke projecten leveren ook een deel van hun bestaande vindbaarheidssignaal in.
Doe een droogloop voordat je de canonieke remote omzet: migreer één representatieve repository, bouw de integraties opnieuw op, test issue- en pull-requestgeschiedenis, en leg het terugrolpad vast. De platformvergelijking komt ná die afhankelijkheidsaudit.
Voor teams die non-profitgovernance willen zonder zelf een server te draaien, is Codeberg het overwegen waard.
Praktische tip over soevereiniteit. Kies je voor zelf hosten vanwege EU-dataresidentie, dan doet de locatie van het datacenter ertoe. Plekken als Frankfurt of Amsterdam zijn de saaie maar juiste keuze. De goedkoopste VPS in Virginia helpt je verwerkersovereenkomst niet.
De operationele kosten van publieke Git-hosting
Publiek zelf hosten stelt een forge bloot aan hetzelfde geautomatiseerde verkeer dat elke vanaf internet bereikbare applicatie treft, alleen bevatten repositorypagina's dure paden zoals blame-weergaven, archieven en commitgeschiedenis. De verslagen hieronder zijn individuele beheerderservaringen, geen benchmarks.
In de eerder genoemde discussie over zelfgehoste Git meldde een beheerder 37.212.377 requests tegen een cgit-instantie in 60 dagen, waarvan meer dan 99% als bots werd geclassificeerd.
In dezelfde discussie vertelt kstrauser een Forgejo-instantie van zo'n 600.000 requests per dag naar ongeveer 1.000 te hebben gebracht, maar pas na een JavaScript-en-cookie-challenge bovenop de gebruikelijke maatregelen.
Andere beheerders noemden fail2ban, GeoIP-blokkades, blackholes op het niveau van autonome systemen, en repositories terugbrengen naar gehoste platforms. Deze verslagen tonen mogelijke faalvormen; het zijn geen universele verkeersreferenties.
De technische reden dat dit lastig is: eenvoudige rate limiting per IP kan falen tegen verkeer dat rouleert via residentiële proxy's. Een scraperzwerm kan requests over zoveel IP's spreiden dat geen enkel adres misbruikend oogt, terwijl de server in totaal alsnog bezwijkt.
JavaScript- of cookie-challenges kunnen ongeraffineerd scrapen terugdringen, maar ze kunnen ook gebruikers zonder JavaScript buitensluiten en Git-over-HTTPS verstoren als je ze op elk pad toepast. CDN-caching helpt bij herhaalde leesacties; bij unieke of dure endpoints zoals archieven, blame-weergaven en pagina's per commit helpt het veel minder.
Wat een challenge verandert, is de economie ervan. Anubis gaat vóór een forge staan en laat een client een challenge afronden, bijvoorbeeld een kleine proof-of-workberekening, voordat de server de beschermde pagina teruggeeft, wat grootschalig crawlen duurder maakt. Het is mitigatie, geen garantie.
Pas browserchallenges selectief toe. Houd SSH beschikbaar voor Git-operaties, en test Git-over-HTTPS voordat je dat pad beschermt: een challengepagina die naar een Git-client gaat, wordt een mislukte clone, geen nuttige verificatie.
GitHub vangt deze verkeersklasse op als onderdeel van zijn gehoste dienst. Een publieke Forgejo- of cgit-instantie laat capaciteitsplanning, misbruikcontroles, caching en mitigatie aan jou over. Die verschuiving van het beheer, niet de kale softwarekosten, is het belangrijke deel van de migratiebeslissing.
Daarom is het hybride model een eersteklas optie en geen terugvaloptie. Privécode achter een VPN: scrapers komen er niet bij. Publieke open source op GitHub: de antimisbruikinfrastructuur van GitHub verwerkt het botverkeer.
Wil je toch een publieke zelfgehoste forge, begroot dan logs, ratecontroles, caching, botmitigatie, monitoring en een geteste route voor Git-verkeer die niet van browserchallenges afhangt. Behandel scraperafweer als onderdeel van de normale bedrijfsvoering, niet als randgeval.
De netwerkeffectvraag voor open-sourcemaintainers
Ik richt me hier tot een heel specifieke lezer: jij onderhoudt een opensourceproject. Twintig bijdragers, tweehonderd sterren en een actieve issue tracker. En je overweegt het weg te halen bij GitHub.
Wees eerlijk over wat je inruilt: vindbaarheid voor bijdragers, het impliciete vertrouwensmerk van github.com, Dependabot, CodeQL en het ecosysteem van derden dat op GitHub-auth leunt. Niets daarvan is elders onmogelijk; alles wordt wrijving.
De vuistregel die ik zou geven: zit de waarde van je project vooral in de code, dan is zelf hosten makkelijker te verantwoorden.
De code reist mee. Hangt de waarde ervan sterk af van bijdragers, issues, vindbaarheid in zoekmachines en het vertrouwen rond github.com, dan ruil je met weggaan een deel van wat het project laat werken in voor wat de maintainer een beter gevoel geeft. Een legitieme ruil als je redenen groot genoeg zijn. Een slechte ruil als je het doet om een punt te maken.
Het platformoverzicht van Codeberg beschrijft een op Forgejo gebaseerde dienst die wordt beheerd door de non-profitvereniging Codeberg e.V. Voor opensourcemaintainers betekent dat communitygovernance zonder de onderhoudslast van zelf een forge draaien.
Voor opensourcegezinde teams die communitygovernance willen zonder upgradeplicht, is dat een kleinere operationele sprong dan zelf een publieke forge draaien. SourceHut is een veel bewustere workflowverandering en vraagt om een aparte afweging.
Maak de kleinste verandering die het probleem oplost
Schrijf voordat je remotes omzet de eis in één zin op: training op Copilot-interactiegegevens stoppen, publieke en private hosting scheiden, of GitHub uit de architectuur halen. Kun je de eis niet benoemen, migreer dan nog niet.
Begin een migratie met één representatieve repository als pilot. Inventariseer authenticatie, Actions, webhooks, packagepublicatie, previewomgevingen, issuegeschiedenis, LFS-data en terugrolstappen voordat je de canonieke remote omzet.
Cloudzy's Forgejo-implementatie met één klik is een snelle manier om de private kant van een hybride model op te zetten; een handmatige installatie op elke Linux VPS werkt ook. Welke route je ook kiest: houd de webinterface privé, maak een back-up van de volledige applicatiestatus, en test het herstel voordat je een kritieke repository verplaatst.
Bouw op een Linux VPS met root-toegang, NVMe en AMD EPYC-kracht.
Bekijk Linux-plannenControle is alleen nuttig als ze de eis oplost tegen exploitatiekosten die je team kan volhouden.
Veelgestelde vragen
Moet ik weg van GitHub vanwege de Copilot-trainingswijziging?
Niet automatisch. Is je enige zorg dat Copilot-interactiegegevens voor modeltraining worden gebruikt, dan is de instelling op accountniveau uitzetten de kleinste juiste oplossing. Migreren is zinvol als je daarnaast strengere eisen hebt rond dataresidentie, governance, leveranciersonafhankelijkheid of een uitsluitend-FOSS-beleid.
Traint GitHub op al mijn privérepositories?
Nee. De hier besproken beleidswijziging dekt de betreffende Copilot-interactiegegevens, inclusief invoer, uitvoer, codefragmenten en bijbehorende context die via Copilot zijn verstuurd. Het betekent niet dat elke privérepository op GitHub automatisch voor modeltraining wordt gebruikt.
Is Git zelf hosten altijd privéer?
Alleen als je hem zo beheert. Een private forge achter een VPN of IP-allowlist kan blootstelling beperken, maar een publiek bereikbare instantie voegt verantwoordelijkheden toe voor patchen, monitoring, botmitigatie, toegangscontrole en back-ups die GitHub normaal opvangt.
Welk zelfgehost Git-platform moet ik kiezen?
Kies Forgejo of Gitea als je een lichtere private forge wilt. Kies GitLab CE als geïntegreerde CI/CD en een package- of containerregistry belangrijk genoeg zijn om de hogere resource- en onderhoudsbehoefte te rechtvaardigen.
Welke VPS-grootte hebben Forgejo of Gitea nodig voor een klein team?
Voor een privéteam van twee tot tien personen zijn 2 vCPU en 4 GB RAM een veiliger startpunt. Voeg capaciteit toe als zoekindexering, packages, grote repositories of CI-runners dezelfde host delen. Dimensioneer GitLab CE apart, want dat vraagt meer resources.
Wat moet ik testen voordat ik de canonieke remote omzet?
Doe een pilot met één representatieve repository. Controleer issue- en pull-requestgeschiedenis, authenticatie, Actions of vervangende CI-workflows, webhooks, packagepublicatie, LFS-data, previewomgevingen, back-ups, herstel en het terugrolpad voordat je alles verplaatst.
