Walgit collected 1,463 GitHub stars within roughly two days of its repository being created, according to MrKeyoor's August 25 snapshot. The attraction is plumbing: one Rust binary, an S3 or Google Cloud Storage bucket, and no separate database or elected leader. The repository describes each server's disk as a disposable cache while the bucket holds the durable record of every push. If that design holds up outside its author's tests, a small team could run Git hosting without assigning permanent repositories to permanent machines.
The scope goes well beyond a minimal git push endpoint. Walgit's README lists smart HTTP fetch and push for Git protocol versions 0 and 2, Git LFS, a repository browser, a JSON API, push rules, OIDC or token authentication, and webhooks. It can run all roles on one machine or split serving, maintenance, and event delivery across several instances. Its main architectural claim is still the part worth examining: the object store is the repository, while local Git repositories can be rebuilt and discarded.
Why Git hosting resists shared storage
A Git repository looks portable because a developer can copy its directory, but its packfiles are awkward remote-storage workloads. Objects are compressed and frequently stored as deltas against other objects. Reading one commit, tree, or blob can trigger a series of jumps through a large packfile. Cursor's engineering account of its own Git service says this random access pattern made network filesystems slow and unreliable, while a complete local copy on NVMe allowed normal Git operations to remain fast.
Large hosts commonly answer that problem with local repositories plus application-level replication. Cursor's account describes the Spokes pattern as keeping consistent copies on several servers, coordinating a reference update with three-phase commit, and tracking which machines hold each repository in a database. That arrangement preserves the immediate consistency Git clients expect after a push, but adding replicas increases coordination and operational work. A popular monorepo wants many read replicas; a rarely touched agent-created repository may not justify three warm copies.
Walgit is an independent, open-source implementation of the newer architecture Cursor calls Continuity. Cursor says its production system writes each push to an S3-backed write-ahead log, keeps ordinary Git repositories as local caches, and uses an atomic compare-and-swap operation to publish updates. Walgit credits that design directly and includes a copy of Cursor's article in its documentation. The projects should not be conflated: Cursor's published throughput numbers describe Continuity, while walgit has its own code, storage back ends, cache policies, and test suite.
One manifest decides when a push exists
A walgit push first arrives as a Git pack. The server indexes it in scratch space, checks object connectivity and repository policy, then uploads the pack, its indexes, and a log entry. Only after those immutable objects exist does it replace a small manifest with a conditional compare-and-swap. The project's documented invariant is precise: the manifest update is the sole commit point, so work before it is invisible and work after it can be replayed. The client receives success only after the bucket has accepted the update.
That conditional write also handles concurrent pushes. If another server changes the manifest first, the loser receives a precondition failure, reads the current state, checks the old values of the affected refs again, and retries. There is no long-lived primary or separate consensus service in this path. There is still coordination, concentrated in the object store's conditional-write semantics. Cursor uses the same basic mechanism in Continuity and notes that choosing a usual primary reduces retries even though any healthy instance can accept a push.
Reads pay for consistency too. Before serving a fetch, an instance conditionally requests the manifest using the version it already has. An unchanged response lets it use its local copy; a changed response makes it apply newer log entries first. Walgit says this check happens on every read, and a cold instance can reconstruct refs from a checkpoint plus the remaining log. The model avoids stale replicas, but it makes object-store availability and request latency part of the Git service's foreground path.
The manifest and log take over state that a routing table and replica inventory would otherwise help manage. Operators now depend on the bucket for durability, conditional writes, range requests, retention, and access control. Walgit's own cost rule says protocol changes must be judged by round trips to the bucket. A deployment therefore needs to measure request charges and tail latency alongside CPU and disk use.
Large clones move away from the Git server
Walgit's most practical addition to Cursor's published outline is its treatment of repositories too large for one server's cache. It can keep commit and tree history locally while leaving large blobs in object storage, then read missing objects through HTTP range requests. The repository also generates scheduled Git bundles, including full and incremental chains, so a new clone can download most bytes from an object store or CDN and ask the live server only for recent changes.
Git already supplies the protocol facility Walgit uses here. Protocol version 2 can advertise a bundle-uri command before fetch. The Git documentation says the client uses those bundles to seed its object database, reducing the large pack it would otherwise request from the origin. The protocol is designed to fall back to a normal fetch when a bundle is missing or unusable, which matters when clone traffic has been offloaded to a CDN.
The result changes which resource limits are acceptable. A small serving instance no longer needs enough disk for every pack in a large repository, and cached clone artifacts can be delivered as static files. Walgit still relies on upstream Git for upload-pack, repacking, and bundle creation, while its own components handle receive-pack, the write-ahead log, remote object reading, and maintenance scheduling. This preserves compatibility with Git's mature object code while placing new correctness obligations around the log and manifest.
Maturity remains unproven
The star count measures developer curiosity; it says nothing about reliability. At the time of the snapshot, GitHub showed three commits, 77 forks, one open issue, and no listed releases or packages. The repository is MIT-licensed and unusually detailed for a new project, but there is not yet a versioned artifact or an independent production record to compare with Cursor's system. Teams evaluating it should build from a pinned commit and treat the current code as early software.
There is meaningful testing material to inspect. The project documents a fast in-memory test tier using real Git, an end-to-end server test, a local S3-compatible storage contract test, and a fault-injection simulation covering crashes, partitions, and stale reads. Those commands and claims are in the repository; MrKeyoor did not run them for this article. A useful evaluation would add simultaneous pushes from several instances, forced conditional-write conflicts, cold recovery of a repository larger than local disk, and loss of bucket access during fetch and push.
Authentication also deserves deployment-specific scrutiny. Walgit supports static tokens and OIDC, while its none mode grants anonymous write access and is labeled for loopback experiments. Its documented OIDC path issues stateless HMAC-signed access tokens and revokes all of them when the signing secret rotates. That is a workable baseline, though organizations still need to test protected refs, webhook delivery, audit needs, secret storage, and restore procedures against their own policies.
The next evidence to watch is concrete: a tagged release, repeatable third-party benchmarks, more contributors reviewing the storage invariants, and failure tests against both S3 and GCS. Walgit's early popularity says the operational problem resonates. Whether its answer is ready for valuable source code will depend on how the manifest protocol behaves under contention and partial failure, and whether cold reads and object-store bills stay acceptable on real repositories. The code and test plan are public, so those claims can be checked rather than taken on faith.