Shopify's CEO Shipped a Git Server. 35 Minutes Became 8 Seconds.

TL;DR

Late on August 23, Shopify cofounder and CEO Tobi Lütke pushed walgit to GitHub: a git server written in Rust whose only durable state is an S3 or GCS bucket. No database, no leader, no node identity. It is an open implementation of Git at any scale, the architecture Cursor published five days earlier for the system it calls Continuity, plus the parts you need to run it on machines smaller than the repository. The headline measurement from the monorepo it was built for: a CI clone that took 2,075 seconds now takes 8. MIT licensed, one binary, 600-plus stars in its first eleven hours.

What actually landed

The repository arrived as a single commit at 22:27 UTC, message walgit: initial public release, one contributor. Under it: 119 Rust files across eight crates, about 2.5 MB of Rust source, a React web UI, a Nix flake, a Containerfile, and sixteen markdown documents. The architecture manual is 43 KB and it is called AGENTS.md, which tells you who the intended second reader is.

What you get for one process pointed at a bucket: git smart HTTP v0 and v2 (fetch with filter, shallow and deepen; atomic receive-pack with push options and report-status-v2), bundle-uri clones served as static files, Git LFS, a browsing web UI on a JSON API with a dependency-free SDK, per-repository push policy, and webhooks. Auth is none, static tokens, or OIDC against any issuer. Stores are S3, anything S3-compatible (MinIO, Ceph, R2, rustfs), GCS, and an in-memory backend for tests.

It is deliberately not a forge. No code review, no issues, no CI, no merge queue. It also does not fork git: upstream git still does upload-pack, repack, bitmaps and bundle creation, with gix used where it measured faster. walgit owns receive-pack, the log, and the plumbing between them.

Why this architecture exists: agents

Cursor did not build Continuity for fun. Its post is blunt about the cause: "Agents have fundamentally changed the way we work with software, and in many ways they've made this situation worse. More code, more PRs, more CI runs." A forge designed for humans typing commits gets a different load profile when a fleet of coding agents is opening branches all day, and Cursor needed to serve both a giant monorepo wanting hundreds of replicas and millions of tiny agent-created repositories wanting almost none.

The old answer was GitHub's Spokes: real repositories on local NVMe, replicated at the packfile level with three-phase commit across a fixed replica set, plus a database mapping every repository to its machines. Cursor's complaint is structural, not incidental. In that design "the latency of every step is bound by the slowest of all the servers in the cluster."

Continuity's move is to put a write-ahead log in object storage and call that the truth. A push uploads an immutable pack plus a log entry, then rewrites one tiny manifest with a compare-and-swap. That CAS is the entire consensus mechanism. Any instance may accept a push; two racing instances cannot both win, because only one CAS can succeed against the version it read.

The mental picture: a shared whiteboard where the only thing anyone is allowed to change is one sticky note in the corner, and only if it still says exactly what you last read. Everyone can staple new pages to the wall whenever they like, but the note decides which pages count.

The part Cursor did not need

Cursor runs Continuity on machines that can hold the repository. walgit's stated goal is the opposite: serve a monorepo of tens of gigabytes, tens of millions of objects and hundreds of thousands of refs from a host with a few GiB of tmpfs. Three additions do that work.

The remote reader. Pack indexes stay local, pack data is read by HTTP range request into a block cache, and the web UI faults in exactly the objects a tree listing or a blob view will touch. Refs, API and UI work for a repository whose packs will never fit on the box.

The history pack. When the base pack is rebuilt, a derived pack of commits and trees is published beside it. Every instance keeps that one locally, described as a few GB for a 57 GiB repository. Only blob bytes cross the network.

Bundles as the transport. The maintainer cuts bundles on calendar slots (a weekly full, chained dailies, hourlies) computed as a pure function of the log, so a missing slot is simply built on the next pass and a deleted bundle is rebuilt byte-identically. A fresh clone pulls the newest full plus the chain above it straight from the bucket or a CDN and asks the server for the remainder. For the reference monorepo that is 32.7 GB of static bytes and 2.8 MB through upload-pack.

Does a bucket actually keep up?

The instinct is that routing every git operation through object storage must be slower than NVMe. Cursor published the throughput it measured on Continuity: up to 120 pushes per second on S3 Standard while compacting and replicating at the same time, and more than 300 per second on S3 Express One Zone. The read path leans on a conditional GET that usually returns a bodyless 304, which Cursor clocks at under 10 ms on average, and synthetic tests scaled reads linearly to 100 replicas.

Five days, two implementations

Cursor's post went up August 18 and hit 362 points on Hacker News the same day. By August 21 there was waltier, an MIT-licensed Rust crate generalizing the idea into "an embeddable tiered write-ahead log coordinated by nothing but S3 conditional writes." By August 23 there was walgit. An architecture went from one company's engineering blog to two independent open-source implementations inside a week, which is roughly the rate at which infrastructure ideas now propagate when the primitive underneath them (conditional writes on object storage) is already sitting in everyone's cloud account.

Caveats, straight

• The performance numbers are self-reported and come from a single monorepo. The announcement says so plainly. Nobody has independently reproduced the 8-second clone.
• The reference repository is not named. The docs say "we" and describe a 57 GiB, 73-million-object monorepo with thousands of developers and their agents. They do not say whose it is, and neither will we.
• It is one day old, one commit, one contributor. There is a fault-injection simulation suite covering crashes, partitions and stale reads, which is more rigor than most day-one projects, and it is still day one.
• It is a host, not a forge. If you want review, issues, or CI, you are wiring those yourself on the JSON API and the webhook bridge.

Why a builder should care

If you self-host git, the operational shape here is the interesting part, independent of the benchmarks. The stated invariant is "Local disk is a cache. Memory is a cache. The bucket is the repository," and the README's summary of what an outage costs you is "Kill them all and you lose warmth, nothing else." Backup strategy becomes bucket versioning. Scaling out becomes starting another process with the same config. Failover becomes nothing, because there was never a primary.

That is also the honest test of the claim. A git host with no database and no leader has moved every hard problem into one compare-and-swap and one conditional GET, and the interesting failures will be the ones nobody has hit yet. But it is MIT, it is one binary, and a bucket costs a few dollars. The barrier to finding out is an afternoon, which is a rounding error next to the three-phase commit you would otherwise be operating.

Key Takeaways

• walgit is real and runnable today: one Rust binary, MIT licensed, pointed at S3 or GCS, with smart HTTP, bundle-uri, LFS, a web UI, push policy and webhooks.
• The architecture is Cursor's Continuity: a write-ahead log in object storage as the source of truth, with a manifest compare-and-swap standing in for leader election and quorum.
• Agents are the reason it exists. Cursor built it because agent-driven volume broke a design that assumed humans wrote every commit.
• walgit's addition is small machines: a remote reader over HTTP range requests, a commits-and-trees history pack, and bundles served as static files, so a host can serve a repository larger than its disk.
• Headline number, self-reported: a filtered, shallow, sparse CI clone of a 57 GiB monorepo went from 2,075 seconds to 8, with 32.7 GB moving from the bucket and 2.8 MB through the server.
• Published architectures now become open source in days. Blog post August 18, waltier August 21, walgit August 23.

Sources: tobi/walgit on GitHub, Cursor, Git at any scale, danthegoodman1/waltier, Hacker News discussion of Git at any scale.