walgit turns Git hosting into one binary over object storage
walgit is an open source Git server, written in Rust and shipped as one binary, that hosts repositories directly in an S3 compatible or GCS bucket instead of on local disk. Setup is a TOML config naming the bucket, a listen address and one or more auth tokens, then a single command, walgit serve, starts the server; a git push to a repository name that does not exist yet creates it. Every machine running walgit is stateless: it caches parts of a repository locally, but nothing on disk matters, and adding more machines pointed at the same bucket just adds more caches serving the same data with nothing to coordinate.
The project frames itself as a fix for a hosting problem specific to Git: repositories are packed into large binary packfiles laid out for size, not for ordered reads, so operations on them are effectively random access over gigabytes. That is fast on a laptop with the file in page cache and slow over a network filesystem, which is why serving repositories from NFS has failed at every large host that tried it. GitHub's own solution, Spokes, keeps real repository copies on local NVMe on each machine and replicates them at the packfile level with strict consistency, which costs a three phase commit across a fixed set of replicas, a database mapping every repository to its machines, and a fleet of individually maintained servers. walgit instead implements the alternative architecture Cursor described in a post called Git at any scale, which Cursor calls Continuity: a write ahead log kept in object storage is the single source of truth, and every on disk repository, wherever it exists, is just a cache of that log.
In walgit's implementation, a push is written as an immutable object in the bucket, then a small manifest file is rewritten with a compare and swap operation to make the push visible; that compare and swap is the entire consensus mechanism, so there is no leader election and no quorum, though any server may accept a push and two racing pushes cannot both win. If the compare and swap fails because someone else committed first, the server gets an HTTP 412 response, rereads the manifest, revalidates every affected ref, and retries. A read works the other way: the server issues one conditional GET on the manifest, and most of the time gets back an HTTP 304 meaning nothing changed, so it serves straight from its local copy; only a real change triggers it to fetch and apply new log entries. Because the log is the only truth, walgit can add features Continuity's original design did not need on larger machines: a remote reader that serves refs and web pages over HTTP range requests for repositories whose packs will never fit on the local disk, keeping commits and trees local while large blobs stay in the bucket, and bundle uri support that lets fresh clones and catch up fetches be served as static files straight from the bucket or a CDN, bypassing the server entirely for that traffic.
Beyond the core hosting protocol, walgit bundles a browsable web UI, Git LFS support, a JSON API with an SDK, per repository push policy, and webhooks, and it can run in front of any number of machines split by role: serving traffic, maintaining a repository (checkpoints, compaction, integrity checks), or bridging webhook events, with which repository is handled by which machine set through configuration rather than inferred automatically. It ships as MIT licensed source with a setup script that installs a Git credential helper needing Git 2.46 or newer, and building the web UI from source requires Node 24. The project documents its own design and invariants in an AGENTS.md file and a cost model in docs/ROUNDTRIPS.md, and its test suite includes a fast in memory tier that finishes in under a minute, an end to end tier against a real Git client that takes about 20 seconds, and a separate fault injection simulation that exercises crashes, network partitions, and stale reads. The source text gives no release version number, no benchmark figures against GitHub, GitLab, or Gitea, and does not name an individual maintainer beyond the GitHub path the project is hosted under.
Key facts
- walgit is a single Rust binary that hosts Git repositories directly in an S3 compatible or GCS bucket, with no database and no local state that has to survive: any machine running it is a disposable cache, and pointing more machines at the same bucket adds more caches of the same repositories with nothing to coordinate.
- It implements the write ahead log architecture Cursor described in a post called Git at any scale, which Cursor calls Continuity: the bucket holds the source of truth in an immutable log, and a compare and swap rewrite of a small manifest file is the only commit point and the entire consensus mechanism, with no leader election or quorum.
- A push gets an HTTP 412 and retries if the compare and swap loses a race; a read does one conditional GET on the manifest and usually gets an HTTP 304, meaning it can serve from a local copy without contacting the rest of the system.
- On top of that log, walgit adds a remote reader that serves a repository too large for the local disk over HTTP range requests, and bundle uri support that serves fresh clones and catch up fetches as static files from the bucket or a CDN rather than through the server.
- It also bundles Git LFS, a web UI, a JSON API and SDK, per repository push policy, and webhooks; it is MIT licensed, needs Git 2.46 or newer for its credential helper and Node 24 to build the web UI, and its test suite includes a fault injection simulation for crashes, partitions and stale reads.
Why it matters
Hosting Git at scale has had two known answers, and both are expensive. Serving repositories straight off a network filesystem fails everywhere it has been tried, because Git packs everything into binary packfiles optimized for size rather than ordered access, and every operation becomes a random walk over gigabytes that a network filesystem cannot absorb. The design that does work, GitHub's Spokes, keeps real repository copies on local NVMe on every machine and replicates them at the packfile level with strict consistency, which means a three phase commit across a fixed set of replicas, a database that tracks which machines hold which repository, and a fleet of servers that each have to be kept individually healthy. walgit is a working implementation of a third approach, one Cursor described and named Continuity: treat a write ahead log in object storage as the only source of truth, and let every on disk repository, on any machine, be nothing more than a cache of that log that can be thrown away and rebuilt. That turns Git hosting from a fleet of stateful machines that must be individually cared for into a stateless service that can be scaled by adding boxes and torn down without a migration.
Who it affects
This is infrastructure for teams that self host Git rather than for anyone using GitHub, GitLab, or a similar hosted service day to day. It targets platform and infrastructure engineers who run Git hosting themselves, in particular for monorepos that have grown past what a single machine can hold on local disk, since walgit is built to serve a repository from a machine smaller than the repository itself. It is not aimed at individual developers choosing where to push code.
How to use it
walgit is released under the MIT license as Rust source. Deployment is a TOML config file naming an S3 compatible or GCS bucket, a listen address, and one or more bearer auth tokens, followed by running walgit serve; pushing to a repository name that does not exist yet creates it automatically. A provided install script sets up a Git credential helper that needs Git 2.46 or newer to use bearer authentication and to clear a stored token automatically on a real authentication failure. Building from source needs the Rust toolchain pinned in the repository, protoc, and Node 24 with pnpm to build the bundled web UI; container and Nix build paths are also provided for a single machine setup with a local object store for testing.
How solid is it
The project documents its own architecture and every design decision, including its invariants, in an AGENTS.md file, and keeps a written cost model in docs/ROUNDTRIPS.md that judges protocol changes by round trips to the bucket rather than by correctness alone. Its test suite runs a fast, fully in memory tier in under a minute, an end to end tier against a real Git client in about 20 seconds, and a separate fault injection simulation that exercises crashes, network partitions, and stale reads specifically. What the source text does not give is a release version number, a changelog, or any benchmark figures, whether for walgit on its own or against GitHub, GitLab, or Gitea, so its performance and scale claims rest on the architecture description rather than on measured numbers.
Risks and caveats
No benchmark numbers appear anywhere in the source, so claims about serving repositories larger than the host machine or about round trip costs are architectural, not measured against real hosted alternatives. The source text names no individual maintainer or organization behind the project beyond the GitHub path it is hosted under, and gives no release version, so how production ready the software currently is stays unstated. Splitting work across machines by role, serving, maintaining, or bridging webhook events, requires the operator to configure placement by hand for each repository rather than having it inferred automatically, which is an added operational step for anyone running more than one machine.
“Every machine that runs walgit is a disposable cache; the bucket is the repository.”
— walgit project documentation