Il 2 giugno 2026 Microsoft ha annunciato la public preview di GitHub Enterprise Local, una soluzione che porta la piattaforma di sviluppo enterprise di GitHub dentro ambienti sovrani e di private cloud, interamente ospitata su infrastruttura di proprietà del cliente. L’obiettivo dichiarato è permettere di modernizzare lo sviluppo applicativo tenendo codice sorgente, pipeline di build e artefatti completamente all’interno del proprio perimetro operativo, di sicurezza e di rete.
Il target è esplicito: governo, difesa, financial services e infrastrutture critiche, ovvero tutte le realtà che operano dentro confini sovrani per ragioni regolatorie, di sicurezza o perché lavorano in ambienti disconnessi.
Cosa è davvero GitHub Enterprise Local?
GitHub Enterprise Local non è una terza variante che entra in concorrenza con le offerte esistenti: è GitHub Enterprise Server (GHES) consegnato come immagine di macchina virtuale precostruita, eseguita su Azure Local come piattaforma di private cloud sottostante.
La VM gira interamente dentro il perimetro di sicurezza e di rete del cliente.
Questo è importante perché ridimensiona il timore della frammentazione di portfolio. Oggi GitHub copre già i vincoli di residenza e sovranità su due fronti: GitHub Enterprise Server, ossia la versione self hosted di GitHub.com che si può installare ad esempio su Azure VMware Solution, e GitHub Enterprise Cloud con Data Residency, che lascia scegliere dove archiviare codice e dati in scope, oggi disponibile in UE, Australia, Stati Uniti e Giappone.
Quindi la versione “Local” non aggiunge un terzo prodotto: prende GHES, lo impacchetta come appliance e lo posa su Azure Local, integrandolo con la gestione Azure Arc e con l’inferenza AI on-premises di Foundry Local.
In pratica, tutti i repository, i metadati, i workflow CI/CD e gli artefatti restano on-premises. La soluzione è progettata per funzionare senza connettività internet by default, quindi è adatta sia ad ambienti connessi sia ad ambienti completamente disconnessi o air gapped, preservando al tempo stesso l’esperienza GitHub a cui gli sviluppatori sono abituati per source control, collaborazione e automazione.
Capacità di sviluppo e di piattaforma
L’insieme di funzionalità è quello atteso da una piattaforma DevOps enterprise completa. I team possono ospitare repository privati, gestire organizzazioni e collaborare tramite pull request, branch protection rule e code review strutturate. Sono disponibili issue, wiki e funzioni di project collaboration, così da coprire l’intero ciclo di sviluppo dentro la stessa piattaforma.
Sul fronte automazione e delivery, GitHub Enterprise Local supporta GitHub Actions con self hosted runner, permettendo di costruire ed eseguire pipeline CI/CD interamente dentro il proprio ambiente, con pieno controllo su contesto di esecuzione, dipendenze e accesso di rete. Per la gestione degli artefatti c’è GitHub Packages, con supporto agli ecosistemi più comuni: npm, NuGet, Maven e container image.
Architettura di riferimento
La soluzione segue un modello a strati ben separati, che vale la pena leggere perché definisce anche chi è responsabile di cosa.
Layer infrastruttura: Azure Local è le fondamenta, fornisce la piattaforma di virtualizzazione su cui gira l’appliance, la gestione di disponibilità e update dell’infrastruttura, networking, identità e policy di sicurezza controllati dal cliente, e la gestione del ciclo di vita tramite Azure Arc.
Layer appliance: GHES viene distribuito come immagine VM precostruita su Azure Local. La VM include lo stack applicativo GHES, dischi dati persistenti per repository e metadati e il supporto a configurazioni di failover basate su replica, a seconda dei requisiti del cliente. Tutti i dati applicativi restano dentro i confini infrastrutturali del cliente.
Layer operations: qui c’è una separazione netta dei ruoli che si sposa bene con i modelli operativi enterprise tradizionali: gli amministratori Azure Local gestiscono l’infrastruttura attraverso Azure, mentre gli amministratori GitHub gestiscono configurazione, upgrade, accessi utente e manutenzione di GHES tramite il GitHub Management control e la site admin dashboard.
Una nota tecnica da non dare per scontata: l’alta disponibilità in produzione, allo stato della preview, arriva dal livello Azure Local. Una singola VM GHES gira su un cluster Azure Local multi nodo, ed è Azure Local a fornire HA e Failover a livello di VM. Non si tratta quindi, oggi, di un clustering applicativo nativo di GHES su più nodi. È una distinzione che incide sul disegno della resilienza e sugli SLA che si possono promettere internamente.
Modalità di connettività
È probabilmente il vero motivo di esistere della soluzione. GHES è progettato per operare completamente offline, quindi è adatto ad ambienti air gapped e ristretti. Azure Local complementa la cosa supportando sia la modalità connessa sia quella completamente disconnessa.
In ambiente connesso si possono sfruttare gestione e monitoraggio centralizzati dell’appliance GHES. In ambiente disconnesso l’intera soluzione può operare in completo isolamento, a garanzia della conformità con mandati stretti di sovranità o sicurezza. Questa flessibilità è ciò che permette di scegliere un modello di deployment allineato ai propri requisiti regolatori, operativi e di sicurezza, invece di subirne uno imposto dal vendor.
Sizing e capacity planning
Il dimensionamento della VM dipende dai casi d’uso concreti: numero di sviluppatori, dimensione e crescita dei repository, frequenza delle pipeline CI/CD e requisiti di storage per gli artefatti.
Azure Local supporta l’esecuzione di GitHub Enterprise Local sia su soluzioni hardware Integrated sia Premier, a patto che ci sia capacità sufficiente. Compute, memoria, storage e rete vanno pianificati di conseguenza, e qui il consiglio pragmatico è di partire sovrastimando lo storage, perché crescita dei repo e ritenzione degli artefatti sono le voci che esplodono per prime in un contesto disconnesso, dove non si può scaricare il problema sull’elasticità del cloud.
Modello di billing
La fatturazione combina tre componenti distinte, ed è bene tenerle separate nei conti perché si sommano:
| Componente | Modello |
|---|---|
| GitHub Enterprise Local | per user seat (licenza GitHub Enterprise) |
| Azure Local | per core fisico di CPU |
| Copilot e Foundry | pricing separato, service based |
La conseguenza pratica è che il costo totale di possesso non è la somma di un solo listino, ma la sovrapposizione di seat sviluppatore, core fisici dell’infrastruttura e servizi AI consumati. Su flotte grandi questo va modellato in anticipo, perché il per core dell’hardware è una voce fissa che prescinde dal fatto che gli sviluppatori usino o meno la piattaforma a pieno.
AI on-premises: Copilot e Foundry Local
La parte interessante, e quella che rende l’annuncio coerente con la traiettoria del 2026, è che l’AI assistita arriva dentro il perimetro senza farne uscire i dati sensibili. Gli sviluppatori possono usare GitHub Copilot in più modi: come esperienza standalone, tramite Copilot CLI e dentro VS Code.
Sul dove gira il modello c’è una scelta esplicita. Si possono usare i modelli gestiti da GitHub connettendosi a GitHub.com, oppure connettersi direttamente ai provider di modelli da Copilot CLI, permettendo al codice sorgente di non transitare per il cloud di GitHub. E soprattutto c’è Foundry Local, che fornisce un layer di inferenza on premises mantenendo prompt, contesto di codice ed esecuzione del modello dentro i confini organizzativi. È il pezzo che chiude il cerchio: si moderna l’esperienza dello sviluppatore senza rinunciare a controllo operativo, compliance e auditabilità.
Come adottarlo in modo industrializzabile: un percorso a fasi
La soluzione stessa suggerisce una progressione naturale, che conviene seguire invece di puntare subito alla produzione.
Fase 1, validazione: single node Azure Local con GHES come VM standalone. È il setup pensato esplicitamente per preview, proof of concept e scenari a basso rischio, focalizzato su semplicità e contenimento dei costi. Qui si valida il fit funzionale e si misura il sizing reale sui propri repo.
Fase 2, produzione: la stessa singola VM GHES gira su un cluster Azure Local multi nodo, dove l’infrastruttura fornisce HA e failover a livello di VM. Il salto non è applicativo, è infrastrutturale, quindi va pianificato lato Azure Local (nodi, storage, rete) più che lato GHES.
Fase 3, modello operativo: si formalizza la separazione dei ruoli, amministratori Azure Local su Azure da una parte, amministratori GitHub sulla site admin dashboard dall’altra. È il momento di definire le runbook per gli aggiornamenti, che in un contesto disconnesso diventano un processo manuale e schedulato, non un automatismo.
Fase 4, supply chain disconnessa: è il punto che fa la differenza tra un PoC e un sistema di produzione air gapped: come si aggiornano GHES e le immagini dei runner self hosted offline, come si alimentano i mirror dei package, come si tengono aggiornati i feed di vulnerabilità. Va progettato prima, non dopo.
Quanto Microsoft sta spingendo sull’hybrid cloud
Qui l’annuncio va letto in controluce, perché da solo dice poco, ma messo in fila con il resto racconta una strategia precisa.
Microsoft sta ricostruendo l’intero stack del proprio cloud su infrastruttura di proprietà del cliente, gestita via Azure Arc e abilitata alla sovranità. In passato abbiamo già parlato di Microsoft 365 Local per comunicazione e collaborazione ora avremo a che fare anche con Foundry Local per i workload AI e GitHub Enterprise Local per lo sviluppo.
Il pattern è inequivocabile: prendere ogni layer del cloud Microsoft e renderlo eseguibile dentro il datacenter del cliente.
GitHub Enterprise Local ha senso per chi ha un vincolo di sovranità o di air gap reale e non negoziabile, e già investe o intende investire su Azure Local come piattaforma di private cloud. Per queste realtà, avere GHES come appliance integrata, con AI on-premises e gestione Arc, riduce in modo concreto l’attrito di un setup che altrimenti andrebbe assemblato a mano.
Per chi invece non ha un obbligo stringente di residenza o isolamento, il calcolo cambia: GitHub Enterprise Cloud con Data Residency offre gran parte della tranquillità sui dati senza l’onere infrastrutturale e operativo del gestire hardware certificato, core fisici e update offline.
La domanda da porsi, prima di tutto il resto, non è tecnica ma di compliance: il mio vincolo è davvero il disconnesso, o mi basta sapere dove risiedono i dati.
La risposta a questa domanda decide quale delle tre strade (Cloud, Cloud con Data Residency, Local) è quella giusta.
La public preview è disponibile da subito, su richiesta tramite il modulo di registrazione alla preview.
