Il 24 aprile 2026, la policy di addestramento dei modelli di GitHub è cambiata per i piani Copilot individuali. GitHub può ora usare le interazioni di Copilot Free, Pro, Pro+ e Max, inclusi input, output, frammenti di codice e contesto associato, per addestrare e migliorare modelli di IA, a meno che l'utente non rinunci. I dati di Copilot Business ed Enterprise restano protetti dall'accordo sulla protezione dei dati di GitHub. Il punto cruciale: si tratta dei dati di interazione con Copilot, non dei repository privati che stanno semplicemente inutilizzati su GitHub.
Nello stesso periodo gli argomenti a favore della migrazione sono riemersi per un motivo diverso: le istanze Git self-hosted pubbliche stavano assorbendo traffico automatizzato pesante. Una discussione su Hacker News ha raccolto una serie utile di resoconti degli operatori su quel problema: Fine di un'era per me: basta git self-hosted.
Resta quindi una domanda più utile di «GitHub o self-hosting?»: quale preoccupazione stai davvero cercando di risolvere?
La versione breve
Tre risposte. Scegli quella che si adatta alla tua situazione.
- A: Rinuncia e resta. Usala quando la modifica sull'addestramento di Copilot è la tua unica preoccupazione e GitHub è ancora adatto alle esigenze operative del team. Disattiva l'impostazione a livello di account e vai avanti.
- B: Adotta un modello ibrido. Tieni l'OSS pubblico su GitHub per l'effetto rete. Sposta il codice privato su un'istanza self-hosted di Forgejo, Gitea o GitLab CE dietro una VPN o una allowlist di IP. Usala quando portata pubblica e controllo privato contano allo stesso tempo.
- C: Migra completamente. Sposta tutto fuori da GitHub. Usala quando normative, residenza dei dati, governance o una policy solo software libero escludono GitHub e il team può sostenere il costo operativo.
La maggior parte dei lettori si trova nella posizione A o B. La posizione C si giustifica con requisiti più severi di governance, sovranità o valori, non con la sola impostazione di Copilot.
Che cosa è cambiato davvero ad aprile 2026
La modifica tecnica è piccola. Nelle impostazioni di Copilot, gli abbonati individuali possono portare «Allow GitHub to use my data for AI model training» su Disabled. GitHub descrive il materiale coinvolto come le interazioni con le sue funzionalità e i suoi servizi, inclusi input, output, frammenti di codice e contesto associato, non i contenuti di repository privati che non sono mai passati per Copilot.
Copilot Business ed Enterprise non mostrano questo interruttore perché i loro dati sono protetti dall'accordo sulla protezione dei dati di GitHub. Per i piani individuali, disattivare l'impostazione risponde alla preoccupazione sulla policy di addestramento; non risolve un'obiezione più ampia al dipendere da una policy controllata dal fornitore.
La modifica a Copilot può essere l'innesco senza essere tutto il caso. Un team può anche tenere alla dipendenza dalla piattaforma, all'identità legata a GitHub, ai flussi costruiti attorno ad Actions, alla residenza dei dati o a quanto sarebbe facile spostarsi di nuovo in futuro. Queste sono domande sulla migrazione; l'interruttore sull'addestramento è solo un'impostazione.
Questa distinzione conta: rinunciare cambia una singola impostazione sull'uso dei dati, mentre migrare cambia chi controlla hosting, identità, integrazioni e policy. La seconda decisione comporta un costo operativo molto più alto.
Le tre posizioni spiegate
La decisione compressa in tre righe. I dettagli più sotto.
| La tua preoccupazione | Risposta | Cosa fare |
|---|---|---|
| I miei dati di interazione con Copilot usati per l'addestramento | Rinuncia e resta (posizione A) | Cambia l'impostazione e torna al lavoro |
| Codice privato che non voglio su un fornitore statunitense + OSS attivo che non voglio nascondere | Ibrido (posizione B) | Ospita i repository privati in proprio dietro una VPN; tieni l'OSS pubblico su GitHub |
| Sovranità, settore regolamentato, scelta di principio solo software libero, piena indipendenza dal fornitore | Migrazione completa (posizione C) | Sposta tutto; metti a budget il costo operativo |
Posizione A: rinuncia e resta
Se sei uno sviluppatore singolo o un piccolo team con repository privati e la tua unica lamentela è l'impostazione predefinita sull'addestramento, questa è la tua risposta. Cambiare un'impostazione: un minuto, una volta sola. Self-hosting: una piccola bolletta VPS, una strategia di backup che collaudi davvero, integrazioni da ricostruire perché davano per scontata l'autenticazione GitHub, e l'occasionale aggiornamento o ripristino che capita nel momento peggiore possibile.
Il self-hosting può comunque valerne la pena, ma solo se quel lavoro ricorrente ti compra qualcosa di cui hai davvero bisogno.
L'obiezione più forte: anche quell'interruttore è una decisione del fornitore. Nel 2026 GitHub è passato dal non usare per impostazione predefinita questi dati di interazione per l'addestramento all'usarli per impostazione predefinita, e potrebbe cambiare policy di nuovo.
Se la tua preoccupazione di fondo è «non voglio mai che un fornitore statunitense prenda decisioni unilaterali sul mio codice», nessuna casella la risolve, e la posizione A è la risposta sbagliata per te. Salta alla posizione C.
Ma se la tua preoccupazione è nello specifico «non voglio i miei attuali dati di interazione con Copilot nell'addestramento» e ti fiderai dell'impostazione di GitHub fino al prossimo cambiamento, la posizione A è la risposta corretta più economica. Non c'è nulla di male nell'essere economici e corretti.
Posizione B: adottare un modello ibrido
L'hosting ibrido separa la portata pubblica dal controllo privato.
La divisione è semplice. L'OSS pubblico resta su GitHub: effetto rete, flusso di contributori, Dependabot e l'ecosistema Actions sono valore reale. Il codice privato si sposta su un'istanza self-hosted dietro una VPN o una allowlist di IP, mai raggiungibile dalla rete pubblica.
Il motivo per cui funziona è una proprietà del modello di minaccia. La preoccupazione sull'addestramento di Copilot riguarda solo i dati di interazione che invii tramite GitHub. Il problema del traffico degli scraper di IA (sezione successiva) riguarda solo le istanze raggiungibili pubblicamente. Un assetto ibrido privato aggira entrambi.
Per un team privato da 2 a 10 persone, 2 vCPU e 4 GB di RAM sono un punto di partenza più sicuro per Forgejo o Gitea, con più margine se indicizzazione della ricerca, pacchetti o CI condividono lo stesso host. Consideralo dimensionamento per Forgejo/Gitea, non per GitLab CE: il tutorial di GitLab per l'installazione su nodo singolo parte da 8 vCPU e 7,2 GB di memoria, prima ancora del carico di CI.
Non esporre l'interfaccia web in chiaro sulla 80 o sulla 443. Limitala a livello di firewall, proxy, VPN o rete mesh. I runner di CI possono servire entrambi i lati.
La scelta della piattaforma cambia il set di funzionalità più del modello ibrido stesso. Forgejo e Gitea si adattano a una forge privata più leggera; GitLab CE ha più senso quando ti serve anche uno stack integrato di CI/CD e registry.
I backup sono gestibili, ma non ridurli a un git bundle. La guida ufficiale all'aggiornamento di Forgejo considera come backup affidabile uno snapshot sincronizzato, a un dato istante, di tutto lo storage usato da Forgejo e, dove non è praticabile, un dump di Forgejo abbinato a un dump separato di PostgreSQL o MySQL. Sia per Forgejo sia per Gitea, tieni insieme repository, database, configurazione, allegati e dati LFS, conserva una copia fuori dal server e collauda un ripristino.
Il clone locale di uno sviluppatore può recuperare il codice, ma non le issue, gli utenti, i metadati delle pull request, gli allegati o tutti gli oggetti LFS. Se un fork privato diventa pubblico in seguito, spingilo verso un mirror su GitHub in quel momento.
Posizione C: migrazione completa quando il controllo è un requisito
La migrazione completa è la scelta più chiara quando l'indipendenza dal fornitore è un requisito e non una preferenza.
Tre gruppi spiccano: team regolamentati con regole di audit, residenza o controllo del fornitore che escludono GitHub; team del settore pubblico o europei i cui requisiti di sovranità sono norma e non preferenza; e organizzazioni solo software libero che vogliono uscire da un'infrastruttura di proprietà Microsoft e hanno già personale in grado di gestire servizi Linux.
Il costo è un piccolo VPS, manutenzione continua e perdita di integrazioni. La perdita di integrazioni è la parte che si dimentica. Tutto ciò che si autentica con «Sign in with GitHub» resta su GitHub o richiede un provider di identità separato.
Pianifica la migrazione attorno alle dipendenze, non solo ai repository. Anteprime delle PR, Actions di terze parti, bot, webhook, registri di pacchetti e integrazioni «Sign in with GitHub» possono richiedere nuove credenziali, nuovi flussi o servizi sostitutivi. Stelle e watcher non diventano record nativi sulla nuova forge, quindi i progetti pubblici rinunciano anche a parte del loro attuale segnale di scoperta.
Fai una prova a vuoto prima di cambiare il remote canonico: migra un repository rappresentativo, ricostruisci le sue integrazioni, verifica la cronologia di issue e pull request e documenta il percorso di rollback. Il confronto tra piattaforme viene dopo quell'audit delle dipendenze.
Per i team che vogliono una governance no profit senza gestire un server, Codeberg merita considerazione.
Consiglio pratico sulla sovranità. Se scegli il self-hosting per motivi di residenza dei dati nell'UE, la posizione del datacenter conta. Sedi come Francoforte o Amsterdam sono la scelta noiosa ma corretta. Il VPS più economico in Virginia non aiuta il tuo DPA.
Il costo operativo dell'hosting Git pubblico
Il self-hosting pubblico espone una forge allo stesso traffico automatizzato che colpisce qualsiasi applicazione affacciata su internet, solo che le pagine dei repository includono percorsi costosi come le viste blame, gli archivi e la cronologia dei commit. I resoconti che seguono sono esperienze di singoli operatori, non benchmark.
Nella discussione sul Git self-hosted citata prima, un operatore ha riportato 37.212.377 richieste contro un'istanza cgit in 60 giorni, con oltre il 99% classificate come bot.
Nella stessa discussione, kstrauser ha raccontato di aver portato un'istanza Forgejo da circa 600.000 richieste al giorno a circa 1.000, ma solo dopo aver aggiunto una sfida basata su JavaScript e cookie sopra le mitigazioni standard.
Altri operatori hanno citato fail2ban, blocchi GeoIP, blackhole a livello di sistema autonomo e il riportare i repository su piattaforme gestite. Questi resoconti mostrano possibili modalità di guasto; non sono valori di riferimento universali sul traffico.
Il motivo tecnico per cui è difficile: un semplice rate limiting per IP può fallire contro traffico che ruota su proxy residenziali. Una flotta di scraper può distribuire le richieste su abbastanza IP da far sì che nessun singolo indirizzo sembri abusivo, mentre il server viene comunque travolto nel complesso.
Le sfide JavaScript o cookie possono ridurre lo scraping poco sofisticato, ma possono anche bloccare gli utenti senza JavaScript e interferire con Git su HTTPS se applicate a ogni percorso. La cache CDN aiuta sulle letture ripetute; aiuta molto meno sugli endpoint unici o costosi come archivi, viste blame e pagine per singolo commit.
Ciò che una sfida cambia è l'economia della cosa. Anubis si mette davanti a una forge e obbliga un client a completare una sfida, per esempio un piccolo calcolo di proof of work, prima che il server restituisca la pagina protetta, il che rende più costoso il crawling ad alto volume. È una mitigazione, non una garanzia.
Applica le sfide del browser in modo selettivo. Tieni SSH disponibile per le operazioni Git e collauda Git su HTTPS prima di proteggere quel percorso; una pagina di sfida restituita a un client Git diventa un clone fallito, non una verifica utile.
GitHub assorbe questa classe di traffico come parte del suo servizio gestito. Un'istanza pubblica di Forgejo o cgit lascia a te la pianificazione della capacità, i controlli antiabuso, la cache e le mitigazioni. È quel trasferimento operativo, non il costo puro del software, la parte importante della decisione di migrare.
È per questo che il modello ibrido è un'opzione di prima scelta e non un ripiego. Codice privato dietro una VPN: gli scraper non ci arrivano. OSS pubblico su GitHub: l'infrastruttura antiabuso di GitHub si occupa del traffico dei bot.
Se vuoi comunque una forge pubblica self-hosted, metti a budget log, controlli di frequenza, cache, mitigazione dei bot, monitoraggio e un percorso collaudato per il traffico Git che non dipenda dalle sfide del browser. Tratta la difesa dagli scraper come parte del normale esercizio, non come un caso limite.
La questione dell'effetto rete per i manutentori open source
Qui mi rivolgo a un lettore ben preciso: mantieni un progetto open source. Venti contributori, duecento stelle e un issue tracker attivo. E stai valutando di portarlo via da GitHub.
Sii onesto su ciò che stai barattando: la scopribilità da parte dei contributori, il marchio di fiducia implicito di github.com, Dependabot, CodeQL e l'ecosistema di terze parti che si appoggia all'autenticazione GitHub. Nulla di tutto ciò è impossibile altrove; tutto però diventa attrito.
La regola pratica che proporrei: se il valore del tuo progetto sta soprattutto nel codice, il self-hosting è più facile da giustificare.
Il codice viaggia. Ma se il suo valore dipende in buona parte da contributori, issue, visibilità nelle ricerche e fiducia legata a github.com, allora andarsene baratta una parte di ciò che fa funzionare il progetto con ciò che fa sentire meglio il manutentore. Baratto legittimo se le tue ragioni sono abbastanza grandi. Pessimo baratto se lo fai per dimostrare qualcosa.
La panoramica della piattaforma Codeberg descrive un servizio basato su Forgejo gestito dall'associazione no profit Codeberg e.V. Per i manutentori open source significa governance della comunità senza il peso di manutenzione di gestire la forge da soli.
Per i team vicini all'open source che vogliono governance della comunità senza l'obbligo di aggiornare, è un salto operativo più piccolo rispetto a gestire una forge pubblica. SourceHut è un cambio di flusso di lavoro molto più deliberato e richiede una valutazione a parte.
Fai il cambiamento più piccolo che risolve il problema
Prima di cambiare i remote, scrivi il requisito in una frase: fermare l'addestramento sui dati di interazione con Copilot, separare hosting pubblico e privato, oppure togliere GitHub dall'architettura. Se non riesci a nominare il requisito, non migrare ancora.
Per una migrazione, parti con un repository rappresentativo come pilota. Fai l'inventario di autenticazione, Actions, webhook, pubblicazione dei pacchetti, ambienti di anteprima, cronologia delle issue, dati LFS e passi di rollback prima di cambiare il remote canonico.
Di Cloudzy distribuzione di Forgejo con un clic è un modo rapido per allestire il lato privato di un modello ibrido; un'installazione manuale su un qualsiasi Linux VPS funziona altrettanto bene. Qualunque strada scegli, tieni privata l'interfaccia web, esegui il backup dell'intero stato dell'applicazione e collauda il ripristino prima di spostare un repository critico.
Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.
Vedi piani LinuxIl controllo è utile solo quando risolve il requisito a un costo operativo che il tuo team può sostenere nel tempo.
Domande frequenti
Devo migrare via da GitHub a causa della modifica sull'addestramento di Copilot?
Non automaticamente. Se la tua unica preoccupazione è che i dati di interazione con Copilot vengano usati per addestrare modelli, disattivare l'impostazione a livello di account è la correzione corretta più piccola. Migrare ha senso quando servono anche controlli più stringenti su residenza dei dati, governance, indipendenza dal fornitore o una policy solo software libero.
GitHub si addestra su tutti i miei repository privati?
No. La modifica di policy discussa qui riguarda i dati di interazione con Copilot che vi rientrano, inclusi input, output, frammenti di codice e contesto associato inviati tramite Copilot. Non significa che ogni repository privato conservato su GitHub venga automaticamente usato per addestrare modelli.
Il Git self-hosted è sempre più privato?
Solo se la gestisci così. Una forge privata dietro una VPN o una allowlist di IP può ridurre l'esposizione, ma un'istanza raggiungibile pubblicamente aggiunge responsabilità di patching, monitoraggio, mitigazione dei bot, controllo degli accessi e backup che normalmente GitHub assorbe.
Quale piattaforma Git self-hosted dovrei scegliere?
Scegli Forgejo o Gitea se vuoi una forge privata più leggera. Scegli GitLab CE quando CI/CD integrata e un registry di pacchetti o container contano abbastanza da giustificare i suoi requisiti più alti di risorse e manutenzione.
Che dimensione di VPS servono a Forgejo o Gitea per un piccolo team?
Per un team privato da due a dieci persone, 2 vCPU e 4 GB di RAM sono un punto di partenza più sicuro. Aggiungi capacità quando indicizzazione della ricerca, pacchetti, repository grandi o runner di CI condividono l'host. Dimensiona GitLab CE a parte, perché richiede più risorse.
Cosa dovrei collaudare prima di cambiare il remote canonico?
Fai un pilota su un repository rappresentativo. Verifica la cronologia di issue e pull request, l'autenticazione, Actions o i flussi di CI sostitutivi, i webhook, la pubblicazione dei pacchetti, i dati LFS, gli ambienti di anteprima, i backup, il ripristino e il percorso di rollback prima di spostare tutto.
