Den 24. april 2026 ændrede GitHubs politik for modeltræning sig for individuelle Copilot-abonnementer. GitHub må nu bruge interaktioner fra Copilot Free, Pro, Pro+ og Max, herunder input, output, kodestumper og tilhørende kontekst, til at træne og forbedre AI-modeller, medmindre brugeren fravælger det. Data fra Copilot Business og Enterprise er fortsat beskyttet af GitHubs databeskyttelsesaftale. Det afgørende: det handler om Copilot-interaktionsdata, ikke private repositories, der bare ligger ubrugte på GitHub.
Samtidig dukkede migrationsargumenterne op igen af en anden grund: offentlige selvhostede Git-instanser absorberede tung automatiseret trafik. En diskussion på Hacker News samlede en nyttig række driftsrapporter om det problem: Slutningen på en æra for mig: ikke mere selvhostet git.
Tilbage står et mere nyttigt spørgsmål end "GitHub eller selvhosting?": hvilket problem prøver du egentlig at løse?
Den korte version
Tre svar. Vælg det, der passer til din situation.
- A: Fravælg og bliv. Brug denne, når Copilot-træningsændringen er din eneste bekymring, og GitHub stadig passer til dit teams driftsbehov. Slå indstillingen fra på kontoniveau, og kom videre.
- B: Kør hybrid. Behold offentlig open source på GitHub for netværkseffektens skyld. Flyt privat kode til en selvhostet Forgejo-, Gitea- eller GitLab CE-instans bag en VPN eller en IP-allowlist. Brug denne, når offentlig rækkevidde og privat kontrol tæller på samme tid.
- C: Migrer fuldt ud. Flyt alt væk fra GitHub. Brug denne, når regulering, dataresidens, governance eller en ren FOSS-politik udelukker GitHub, og teamet kan bære driftsomkostningen.
De fleste læsere er i position A eller B. Position C retfærdiggøres af strengere krav til governance, suverænitet eller værdier, ikke af Copilot-indstillingen alene.
Hvad der faktisk ændrede sig i april 2026
Den tekniske ændring er lille. I Copilot-indstillingerne kan individuelle abonnenter sætte "Allow GitHub to use my data for AI model training" til Disabled. GitHub beskriver det omfattede materiale som interaktioner med sine funktioner og tjenester, herunder input, output, kodestumper og tilhørende kontekst, ikke indholdet i private repositories, der aldrig har været igennem Copilot.
Copilot Business og Enterprise viser ikke denne kontakt, fordi deres data er beskyttet af GitHubs databeskyttelsesaftale. For individuelle abonnementer løser en deaktivering bekymringen om træningspolitikken; den løser ikke den bredere indvending mod at afhænge af en politik, leverandøren styrer.
Copilot-ændringen kan være udløseren uden at være hele sagen. Et team kan også bekymre sig om platformafhængighed, identitet bundet til GitHub, arbejdsgange bygget op om Actions, dataresidens eller hvor let det bliver at flytte igen senere. Det er migrationsspørgsmål; træningskontakten er kun én indstilling.
Den skelnen betyder noget: at fravælge ændrer én indstilling for databrug, mens en migrering ændrer, hvem der kontrollerer hosting, identitet, integrationer og politik. Den anden beslutning koster langt mere i drift.
De tre positioner forklaret
Beslutningen komprimeret til tre rækker. Detaljer nedenfor.
| Din bekymring | Svar | Hvad man skal gøre |
|---|---|---|
| Mine Copilot-interaktionsdata bruges til træning | Fravælg og bliv (position A) | Slå indstillingen om, og kom tilbage til arbejdet |
| Privat kode, jeg ikke vil have hos en amerikansk leverandør, + aktiv open source, jeg ikke vil skjule | Hybrid (position B) | Hjemtag private repositories bag en VPN; behold offentlig open source på GitHub |
| Suverænitet, reguleret branche, principiel ren FOSS-linje, fuld leverandøruafhængighed | Fuld migrering (position C) | Flyt alt; budgettér driftsomkostningen |
Position A: Fravælg og bliv
Er du soloudvikler eller et lille team med private repos, og din eneste indvending er standardindstillingen for træning, så er det her dit svar. At slå en indstilling om: ét minut, én gang. At hoste selv: en lille VPS-regning, en backupstrategi, du rent faktisk tester, integrationer der skal bygges om, fordi de forudsatte GitHub-login, og den lejlighedsvise opgradering eller gendannelse, der lander på det værst tænkelige tidspunkt.
Selvhosting kan stadig være det værd, men kun hvis det tilbagevendende arbejde køber dig noget, du faktisk har brug for.
Det stærkeste modargument: kontakten er også en leverandørbeslutning. I 2026 gik GitHub fra som udgangspunkt ikke at bruge disse interaktionsdata til træning til som udgangspunkt at bruge dem, og de kan ændre politikken igen.
Er din underliggende bekymring "jeg vil aldrig have, at en amerikansk leverandør træffer ensidige beslutninger om min kode", så løser ingen afkrydsningsboks det, og position A er det forkerte svar for dig. Spring videre til position C.
Men er din bekymring specifikt "jeg vil ikke have mine nuværende Copilot-interaktionsdata med i træningen", og stoler du på GitHubs indstilling indtil næste gang noget ændrer sig, så er position A det billigste rigtige svar. Der er ingen skam i billigt og rigtigt.
Position B: Kør en hybridmodel
Hybrid hosting adskiller offentlig rækkevidde fra privat kontrol.
Opdelingen er enkel. Offentlig open source bliver på GitHub: netværkseffekt, tilstrømning af bidragydere, Dependabot og Actions-økosystemet er reel værdi. Privat kode flytter til en selvhostet instans bag en VPN eller IP-allowlist, aldrig tilgængelig fra det offentlige internet.
At det virker, er en egenskab ved trusselsmodellen. Bekymringen om Copilot-træning gælder kun de interaktionsdata, du sender gennem GitHub. Problemet med AI-scrapertrafik (næste afsnit) gælder kun offentligt tilgængelige instanser. En privat hybridopsætning smyger uden om begge.
For et privat team på 2 til 10 personer er 2 vCPU og 4 GB RAM et sikrere udgangspunkt til Forgejo eller Gitea, med mere luft hvis søgeindeksering, pakker eller CI deler samme maskine. Betragt det som Forgejo/Gitea-dimensionering, ikke GitLab CE-dimensionering: GitLabs vejledning til installation på én node starter ved 8 vCPU og 7,2 GB hukommelse, før CI-belastning overhovedet er regnet med.
Lad ikke webgrænsefladen ligge åbent på 80 eller 443. Begræns den på firewall-, proxy-, VPN- eller mesh-netværksniveau. CI-runnere kan betjene begge sider.
Valget af platform ændrer funktionssættet mere end selve hybridmodellen. Forgejo og Gitea passer til en lettere privat forge; GitLab CE giver mere mening, når du også har brug for en integreret CI/CD- og registry-stak.
Backups er til at håndtere, men reducér dem ikke til en git bundle. Forgejos officielle opgraderingsvejledning betragter et synkroniseret point-in-time-snapshot af al den lagring, Forgejo bruger, som den pålidelige backup, og hvor det ikke er praktisk muligt, en Forgejo-dump parret med en separat PostgreSQL- eller MySQL-dump. Uanset om du kører Forgejo eller Gitea, så hold repositories, database, konfiguration, vedhæftninger og LFS-data samlet, opbevar en kopi uden for serveren, og test en gendannelse.
En udviklers lokale klon kan redde koden, men ikke issues, brugere, pull request-metadata, vedhæftninger eller alle LFS-objekter. Bliver et privat fork senere offentligt, så push det til et GitHub-mirror på det tidspunkt.
Position C: Fuld migrering, når kontrol er et krav
Fuld migrering passer klarest, når leverandøruafhængighed er et krav og ikke en præference.
Tre grupper skiller sig ud: regulerede teams med regler om revision, dataresidens eller leverandørkontrol, der udelukker GitHub; offentlige eller EU-teams, hvor suverænitetskrav er politik og ikke præference; og rene FOSS-organisationer, der vil væk fra Microsoft-ejet infrastruktur og allerede har folk, der kan drive Linux-tjenester.
Omkostningen er en lille VPS, løbende vedligeholdelse og tab af integrationer. Tabet af integrationer er den del, folk glemmer. Alt, der logger ind med "Sign in with GitHub", bliver på GitHub eller kræver en separat identitetsudbyder.
Planlæg migrationen omkring afhængigheder, ikke kun repositories. PR-previews, tredjeparts-Actions, bots, webhooks, pakkeregistre og "Sign in with GitHub"-integrationer kan kræve nye credentials, nye arbejdsgange eller erstatningstjenester. Stjerner og watchers bliver ikke native poster på den nye forge, så offentlige projekter opgiver også en del af deres eksisterende synlighedssignal.
Lav en tørkørsel, før du skifter den kanoniske remote: migrér ét repræsentativt repository, genopbyg dets integrationer, test issue- og pull request-historik, og dokumentér vejen tilbage. Sammenligningen af platforme kommer efter den afhængighedsgennemgang.
For teams, der vil have nonprofit-governance uden selv at drive en server, er Codeberg værd at overveje.
Et tip om suverænitet. Vælger du selvhosting af hensyn til EU-dataresidens, betyder datacentrets placering noget. Steder som Frankfurt eller Amsterdam er det kedelige, men rigtige valg. Den billigste VPS i Virginia hjælper ikke din databehandleraftale.
Driftsomkostningen ved offentlig Git-hosting
Offentlig selvhosting udsætter en forge for den samme automatiserede trafik, som rammer enhver internetvendt applikation, blot indeholder repository-sider dyre stier som blame-visninger, arkiver og commit-historik. Rapporterne herunder er enkelte operatørers erfaringer, ikke benchmarks.
I den tidligere nævnte diskussion om selvhostet Git rapporterede en operatør 37.212.377 forespørgsler mod en cgit-instans over 60 dage, hvoraf over 99 % blev klassificeret som bots.
I den samme diskussion fortalte kstrauser om at have bragt en Forgejo-instans fra omkring 600.000 forespørgsler om dagen ned til cirka 1.000, men først efter at have lagt en JavaScript- og cookie-udfordring oven på de gængse tiltag.
Andre operatører nævnte fail2ban, GeoIP-blokeringer, blackholing på autonomt system-niveau og at flytte repositories tilbage til hostede platforme. Rapporterne viser mulige fejlmønstre; de er ikke universelle trafikreferencer.
Den tekniske grund til, at det er svært: simpel rate limiting pr. IP kan slå fejl over for trafik, der roterer gennem residential proxies. En scraperflåde kan sprede forespørgsler ud over så mange IP'er, at ingen enkelt adresse ser misbrugende ud, mens serveren alligevel bliver overvældet samlet set.
JavaScript- eller cookie-udfordringer kan mindske usofistikeret scraping, men de kan også blokere brugere uden JavaScript og forstyrre Git over HTTPS, hvis de lægges på alle stier. CDN-caching hjælper ved gentagne læsninger; den hjælper langt mindre ved unikke eller dyre endpoints som arkiver, blame-visninger og sider pr. commit.
Det, en udfordring ændrer, er økonomien i det. Anubis sætter sig foran en forge og får klienten til at gennemføre en udfordring, for eksempel en lille proof-of-work-beregning, før serveren returnerer den beskyttede side, hvilket gør crawling i stor skala dyrere. Det er en afbødning, ikke en garanti.
Brug browserudfordringer selektivt. Hold SSH tilgængelig til Git-operationer, og test Git over HTTPS, før du beskytter den sti; en udfordringsside, der returneres til en Git-klient, bliver til en mislykket klon, ikke et nyttigt verifikationstrin.
GitHub absorberer denne trafikklasse som en del af sin hostede tjeneste. En offentlig Forgejo- eller cgit-instans overlader kapacitetsplanlægning, misbrugskontrol, caching og afbødning til dig. Netop den driftsmæssige overdragelse, ikke de rå softwareomkostninger, er det vigtige i migrationsbeslutningen.
Det er derfor, hybridmodellen er en førsteklasses mulighed og ikke en nødløsning. Privat kode bag en VPN: scrapere kan ikke nå den. Offentlig open source på GitHub: GitHubs misbrugsinfrastruktur håndterer bottrafikken.
Vil du alligevel have en offentlig selvhostet forge, så budgettér med logs, ratekontrol, caching, botafbødning, overvågning og en testet vej for Git-trafik, der ikke afhænger af browserudfordringer. Betragt scraperforsvar som en del af den normale drift, ikke et særtilfælde.
Netværkseffekt-spørgsmålet for open source-vedligeholdere
Her taler jeg til en meget bestemt læser: du vedligeholder et open source-projekt. Tyve bidragydere, to hundrede stjerner og en aktiv issue tracker. Og du overvejer at flytte det væk fra GitHub.
Vær ærlig om, hvad du bytter væk: at bidragydere kan finde projektet, det implicitte tillidsstempel fra github.com, Dependabot, CodeQL og det tredjepartsøkosystem, der bygger på GitHub-login. Intet af det er umuligt andre steder; men alt bliver til friktion.
Den tommelfingerregel, jeg vil give: ligger dit projekts værdi primært i koden, er selvhosting lettere at forsvare.
Koden kan flytte med. Men hvis dens værdi i høj grad afhænger af bidragydere, issues, synlighed i søgning og tilliden omkring github.com, så bytter en flytning en del af det, der får projektet til at fungere, for det, der får vedligeholderen til at have det bedre. En legitim byttehandel, hvis dine grunde er store nok. En dårlig byttehandel, hvis du gør det for at markere en holdning.
Codebergs platformoversigt beskriver en Forgejo-baseret tjeneste drevet af nonprofitforeningen Codeberg e.V. For open source-vedligeholdere betyder det fællesskabsstyring uden vedligeholdelsesbyrden ved selv at drive forgen.
For open source-orienterede teams, der vil have fællesskabsstyring uden opgraderingspligt, er det et mindre driftsmæssigt spring end at drive en offentlig forge. SourceHut er en langt mere bevidst ændring af arbejdsgangen og kræver en selvstændig vurdering.
Lav den mindste ændring, der løser problemet
Før du skifter remotes, så skriv kravet ned i én sætning: stoppe træning på Copilot-interaktionsdata, adskille offentlig og privat hosting, eller fjerne GitHub fra arkitekturen. Kan du ikke sætte ord på kravet, så migrér ikke endnu.
Ved en migrering skal du først køre pilot på ét repræsentativt repository. Lav en optælling af autentificering, Actions, webhooks, pakkeudgivelse, preview-miljøer, issue-historik, LFS-data og tilbagerulningstrin, før du skifter den kanoniske remote.
Cloudzy's Forgejo-udrulning med ét klik er en hurtig måde at sætte den private side af en hybridmodel op på; en manuel installation på en hvilken som helst Linux VPS virker også. Uanset hvilken vej du vælger, så hold webgrænsefladen privat, tag backup af hele applikationens tilstand, og test gendannelsen, før du flytter et kritisk repository.
Byg på en Linux VPS med root-adgang, NVMe og AMD EPYC-kraft.
Se Linux-planerKontrol er kun nyttig, når den løser kravet til en driftsomkostning, dit team kan bære i længden.
Ofte stillede spørgsmål
Bør jeg migrere væk fra GitHub på grund af Copilot-træningsændringen?
Ikke automatisk. Er din eneste bekymring, at Copilot-interaktionsdata bruges til modeltræning, så er det den mindste rigtige løsning at slå indstillingen fra på kontoniveau. Migrering giver mening, når du derudover har brug for strammere styring af dataresidens, governance, leverandøruafhængighed eller en ren FOSS-politik.
Træner GitHub på alle mine private repositories?
Nej. Den politikændring, der omtales her, dækker de omfattede Copilot-interaktionsdata, herunder input, output, kodestumper og tilhørende kontekst sendt gennem Copilot. Det betyder ikke, at ethvert privat repository på GitHub automatisk bruges til modeltræning.
Er selvhostet Git altid mere privat?
Kun hvis du driver den sådan. En privat forge bag en VPN eller IP-allowlist kan mindske eksponeringen, men en offentligt tilgængelig instans lægger ansvar for patching, overvågning, botafbødning, adgangskontrol og backup over på dig, som GitHub normalt tager sig af.
Hvilken selvhostet Git-platform skal jeg vælge?
Vælg Forgejo eller Gitea, hvis du vil have en lettere privat forge. Vælg GitLab CE, når indbygget CI/CD og et pakke- eller container-registry betyder nok til at retfærdiggøre de højere krav til ressourcer og vedligeholdelse.
Hvilken VPS-størrelse kræver Forgejo eller Gitea til et lille team?
For et privat team på to til ti personer er 2 vCPU og 4 GB RAM et sikrere udgangspunkt. Læg kapacitet til, når søgeindeksering, pakker, store repositories eller CI-runnere deler samme maskine. Dimensionér GitLab CE for sig, da den kræver flere ressourcer.
Hvad bør jeg teste, før jeg skifter den kanoniske remote?
Kør en pilot på ét repræsentativt repository. Verificér issue- og pull request-historik, autentificering, Actions eller erstatnings-CI-arbejdsgange, webhooks, pakkeudgivelse, LFS-data, preview-miljøer, backups, gendannelse og tilbagerulningsvejen, før du flytter det hele.
