Tobi Lütke, cofondatore e CEO di Shopify, ha sviluppato e pubblicato come progetto open source walgit, un server Git progettato per funzionare direttamente sopra sistemi di object storage compatibili con S3 o Google Cloud Storage. Il progetto è nato nel corso di un singolo weekend, mentre Lütke stava cercando una soluzione ai limiti dell’infrastruttura Git interna utilizzata da Shopify. walgit è scritto quasi interamente in Rust, viene distribuito con licenza MIT e adotta un’architettura che elimina alcuni dei componenti normalmente necessari per gestire un servizio Git: non utilizza un database relazionale, non richiede un nodo leader e non conserva uno stato locale indispensabile al funzionamento. Il server viene distribuito come un singolo binario che può essere collegato direttamente a un bucket, mentre l’object storage diventa la sorgente persistente dei repository.
L’architettura utilizza un write-ahead log, o WAL, insieme a operazioni compare-and-swap per registrare in modo consistente le modifiche dei repository all’interno dello storage a oggetti. Più istanze di walgit possono quindi essere eseguite contemporaneamente sullo stesso bucket senza richiedere un database centrale che coordini i server. Le macchine che eseguono walgit possono essere trattate come cache sostituibili: aggiungendo nuove istanze si aumenta la capacità del servizio, mentre la loro eventuale perdita non comporta la perdita dei repository, perché lo stato persistente rimane conservato nel bucket. Questa impostazione permette inoltre di eseguire il server su macchine con una capacità locale inferiore alla dimensione dei repository ospitati, mantenendo localmente le strutture necessarie alle operazioni Git e recuperando i dati più pesanti dallo storage remoto.
Una parte importante del progetto riguarda la gestione dei repository di grandi dimensioni. walgit supporta il meccanismo bundle-uri di Git, che permette di distribuire la cronologia attraverso bundle statici ospitati direttamente nell’object storage o serviti tramite CDN. In questo modo un nuovo clone può recuperare gran parte del repository sotto forma di file statici anziché richiedere al server Git di ricostruire e trasferire ogni volta l’intero contenuto. L’implementazione è pensata anche per monorepository molto grandi, come quelli utilizzati internamente da aziende come Shopify. Per i blob binari di grandi dimensioni il server può inoltre effettuare streaming remoto attraverso richieste HTTP Range, evitando che l’intero contenuto debba essere memorizzato sul disco locale della macchina che esegue il servizio.
walgit include già numerose funzionalità normalmente richieste da un servizio Git utilizzabile in produzione. Supporta Smart HTTP nelle versioni del protocollo v0 e v2 per fetch e push, repository basati sia su SHA-1 sia su SHA-256, Git LFS con memorizzazione degli oggetti nel bucket, un’interfaccia web per l’esplorazione dei repository, una JSON API accompagnata da SDK, webhook e policy di push configurabili a livello di singolo repository. Sono previste inoltre modalità di autenticazione mediante token statici oppure OpenID Connect, rendendo possibile l’integrazione con provider di identità come Google, Okta, Keycloak o Microsoft Entra. L’infrastruttura può essere collegata ad AWS S3 e ad altri storage compatibili con il relativo protocollo, tra cui MinIO, Cloudflare R2 e Ceph, oltre a Google Cloud Storage.
Lütke ha indicato come principale ispirazione il lavoro pubblicato da Cursor sull’architettura Continuity, descritta nel documento “Git at any scale”. Cursor ha progettato Continuity partendo dall’idea di spostare lo stato autorevole dei repository dall’host Git locale verso l’object storage, utilizzando i server come cache ricostruibili e un log persistente per registrare le modifiche. Nel sistema descritto da Cursor, il commit dello stato viene effettuato attraverso l’aggiornamento atomico di un manifest, mentre le letture possono essere distribuite tra numerose repliche. Cursor ha riportato nei propri test fino a circa 120 push al secondo utilizzando S3 tradizionale e oltre 300 push al secondo con S3 Express One Zone, con la possibilità di scalare le operazioni di lettura aggiungendo repliche.
walgit riprende questi principi adattandoli a un server Git autonomo e open source capace di operare anche quando il repository supera la capacità della macchina che lo ospita. La configurazione minima prevede un bucket, un file di configurazione e l’avvio del binario con il comando serve; quando è abilitata l’opzione di creazione automatica, un push verso un nuovo percorso può generare direttamente il repository corrispondente. Al momento della pubblicazione il progetto non dispone ancora di release ufficiali o binari precompilati e deve quindi essere costruito dal codice sorgente, ad esempio tramite Cargo, Nix o container. Il repository è già pubblico su GitHub e Lütke lo presenta come un’implementazione sperimentale ma funzionante di un modello nel quale l’object storage costituisce il repository effettivo e ogni server Git diventa un componente temporaneo e sostituibile dell’infrastruttura.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)