Walgit is a Git server backed entirely by object storage, with no database or leader

Walgit, an open-source Git server written in Rust, surfaced on the Hacker News front page with an unusual deployment model: run a single binary, point it at an S3-compatible or Google Cloud Storage bucket, and you have a working Git host with no database, no elected leader and no local state that matters. According to the project's README, a deployment is a short TOML file plus one process; pushing to a new repository name creates the repository, and further instances pointed at the same bucket serve identical content with nothing to coordinate. Shutting every instance down costs only warm caches.

A write-ahead log as the source of truth

The README credits the design to an architecture Cursor described in a post titled "Git at any scale", covering a system called Continuity, adapted here so instances can be smaller than the repositories they serve. The core move is to make a write-ahead log (WAL) in object storage the authoritative record of a repository and to treat every on-disk copy as a cache.

A push is uploaded as an immutable object and becomes visible only when a tiny manifest file is rewritten with a compare-and-swap operation. That swap is the entire consistency mechanism — no elections, no quorum, no primary — and it makes racing writers impossible: whichever instance's swap lands first wins, and a loser that sees a 412 conflict re-reads, re-validates the refs it meant to update and retries. Concurrent pushes arriving at one instance are group-committed into a single swap.

Reads start with a conditional GET of the manifest. A 304 Not Modified means the local copy is current; a 200 means new log entries get applied, with the depth of application varying by what the request needs — refs listings can skip packfiles entirely, while full materialisation is reserved for repacking. Compaction happens once, by whichever instance holds a time-limited lease, and the results are published into the log so other replicas download compacted packs rather than repacking themselves.

Serving repositories larger than the machine

Walgit's additions over Continuity target monorepos on small hardware. A remote reader built on HTTP range requests lets an instance serve refs and web pages for a repository whose packfiles will never fit on its disk, and a "history pack" keeps commits and tree objects local while large blobs stay in the bucket. Clone traffic leaves the server almost entirely: bundle-uri support cuts bundles on calendar slots — a weekly full plus chained daily and hourly bundles — that the bucket or a CDN serves as static files, so a fresh clone downloads bundles and asks the server only for the remainder.

What ships in the binary

The feature list covers smart HTTP v0/v2 fetch and push, including filters, shallow fetches, atomic pushes, push options and both SHA-1 and SHA-256 repositories. There is Git LFS with objects stored in the bucket, a React browsing UI, a read-mostly JSON API with a dependency-free JavaScript SDK, per-repository push policies (protected refs, groups, fast-forward-only rules, bypass lists), and a webhook bridge that tails the WAL and delivers ref events exactly once using a durable cursor. Authentication supports static tokens or any OpenID Connect issuer, and supported stores include AWS S3, MinIO, Cloudflare R2, Ceph and GCS. A maintenance loop derives the desired state from configuration plus the WAL on each pass and performs one bounded unit of the most important outstanding work; the README says missing artefacts are rebuilt identically, so an outage leaves nothing to repair.

Why it matters

The README frames the underlying economics: Git hosting is painful because packfiles compress everything into large binary blobs optimised for size rather than sequential reading, so every operation becomes scattered reads across gigabytes — fine for a laptop's page cache, catastrophic over a network filesystem. GitHub's Spokes design answers this by keeping real repositories on local NVMe and replicating at the packfile level, paying for it with coordinated commits across a fixed replica set and a database mapping repositories to machines.

Walgit's bet is that a compare-and-swap manifest in cheap object storage can replace that coordination layer, making instances disposable and the bucket the system of record, with full provenance — every push and repack sits in the log and the repository can be replayed to any point. For anyone who wants self-hosted Git hosting without a stateful fleet, that changes the cost structure, at the price of depending on the object store for both availability and the CAS semantics the whole design rests on.