Single-binary Git server stores repositories directly in S3 or GCS buckets

Walgit implements a fundamentally different Git hosting architecture that moves the source of truth from local filesystems to object storage. Traditional Git servers like GitHub's Spokes maintain repositories on local NVMe drives and replicate packfiles across a fixed replica set using three-phase commits and a central database. This approach requires complex coordination and dedicated hardware. Walgit eliminates these requirements by treating object storage as a write-ahead log where every push becomes an immutable object, with repository visibility controlled by a single compare-and-swap operation on a manifest file.

The stateless design enables horizontal scaling without coordination overhead. Any number of Walgit instances can serve the same repositories from a shared bucket, with consistency guaranteed by conditional GET operations against the object store. This architecture particularly benefits monorepos and large repositories, as instances can serve repositories larger than their local storage by using HTTP range requests for packfiles and keeping only commit and tree data locally. The system maintains complete provenance through the write-ahead log, allowing replay of all operations to any historical point.

Walgit implements several optimizations for large-scale Git operations. Bundle-URI support allows fresh clones and catch-ups to be served as static files directly from the bucket or CDN, reducing server load. The system supports blobless operations where blobs remain in object storage while commit and tree data is cached locally. For imported repositories, Walgit can optionally read through to an upstream LFS server. These features address common pain points in Git hosting while maintaining compatibility with standard Git clients and protocols.

The deployment model significantly reduces operational complexity. A single configuration file and environment variable setup replaces traditional database configurations, replication topologies, and leader election systems. Instances can be added or removed freely, with no data loss risk beyond temporary cache warmth. The architecture particularly suits cloud-native environments where object storage is already available and ephemeral compute instances are preferred. However, the design assumes reliable object storage with strong consistency guarantees, which may limit deployment options in some environments.