walgit Hit 2,492 Stars in 21 Days on 68,000 Lines of Rust and 85 Commits

On 23 August 2026 a repository called walgit appeared with a single commit labelled "walgit: initial public release." Twenty-one days later, when we pulled the GitHub API on 13 September, it had 2,492 stars, 145 forks and 27 open issues. That is roughly 119 stars a day, sustained, for a git server with no marketing site.

The owner is tobi, which is Tobi Lütke, and the second-largest contributor list entry is Ilya Grigorik. That explains some of the velocity and none of the code, so we cloned it and read it.

What it actually is

walgit hosts git repositories with, in the README's words, "no database, no leader and no local state that matters." You point one binary at an object store and the bucket is the repository. Every machine running walgit is a disposable cache.

The deployment is genuinely three steps, and this is the whole of it:

[server]
listen = "0.0.0.0:8080"
public_url = "https://git.example.com"
auto_create_on_push = true

[store]
backend = "s3"
bucket = "my-walgit"

# then:
#   walgit serve --config walgit.toml
#   git push https://git.example.com/acme/app.git main   <- creates the repo

The mechanism underneath is the part worth understanding. A push is written as an immutable object into the bucket and becomes visible only when a tiny manifest is rewritten with a compare-and-swap. There is no consensus protocol because there is nothing to agree on: the object store's CAS primitive is the only lock in the system. Add more machines pointed at the same bucket and they serve the same repositories. Kill them all and, per the README, "you lose warmth, nothing else."

It is an implementation of the architecture Cursor described in Git at any scale, the system they call Continuity. walgit does not hide this: the post is checked into the repo verbatim at docs/reference/cursor-git-at-any-scale.md, and AGENTS.md instructs contributors to read it once before touching the WAL.

What we could measure, and what we could not

Cloned with full history, here is what is in there:

Measured on the clone	walgit
Rust, total	68,562 lines
Crates	7 (cli, config, git, proto, server, store, wal)
Lines under tests/	19,299 (28% of the Rust)
Inline #[test] / #[tokio::test]	299
Workspace dependency entries	88
Commits, all time	85
Days with any commit, of 21	12
Published release binaries	0

The test ratio is the number we did not expect. A three-week-old project is normally all forward motion and no harness. walgit's largest single file after the git library is crates/walgit-wal/tests/wal.rs, and crates/walgit-server/tests/sim.rs is a simulation harness. The store crate ships a fault.rs alongside its S3, GCS and in-memory backends, which means fault injection was built in rather than bolted on. For a system whose entire correctness argument rests on compare-and-swap behaving under concurrent writers, that is the right place to have spent the effort.

The other number is harder to read charitably. 68,562 lines in 85 commits averages about 807 lines per commit, and 30 of those 85 commits landed on a single day, 12 September, in a run of merges titled packfiles/01-remove-bundles through packfiles/07-seal-evidence. Whatever the process is, it is not incremental.

The manual is addressed to agents

AGENTS.md opens with "architecture and operating manual for contributors (humans and agents)," and is the most disciplined document in the repository. It lays out a document map, the constraints, the WAL, and the working rules, including this one:

No backwards compatibility (pre-1.0). We owe nothing to previous shapes of this system. Do not keep aliases, fallbacks, shims, deprecated routes, old config keys, old proto fields or migration code. When a decision changes the shape, delete the old shape in the same change.

We are not going to claim the code was written by agents, because we cannot see that from a clone and nobody has said it. What we can say is that the repository is built so that it could be: one home per fact, an explicit reading order, a stated bar every PR is judged against, and a rule that forbids the accumulating compatibility cruft that makes a codebase unreadable to anything with a context limit. Read as a systems document it is excellent. Read as a bet about who writes the next 68,000 lines it is more interesting still.

The targets, which are theirs and not ours

The reference workload in AGENTS.md is specific: a 57 GiB monorepo with 73 million objects, 1.4 million commits and 466,000 refs, served from machines whose disk is 20 GiB of tmpfs. The acceptance bar in GOAL.md asks for refs in under a second cold and web pages in roughly 100 ms.

The cost model is stated as object store physics: roughly 60 to 80 ms per GET, about 100 MB/s per connection, a conditional GET around 15 ms, and same-object overwrite serialised to roughly one write per second. That last figure is the honest one, because it names the ceiling the whole design runs into: a single CAS'd manifest object is a throughput cap on pushes to that repository. The docs say so out loud rather than leaving you to find it.

None of those numbers are ours. We could not verify a single one of them, and neither can you without a bucket and a toolchain.

What it does not do

• Code review, pull requests, issues, CI. Explicitly out of scope per GOAL.md. This is a git host, not a forge. If you are replacing GitHub, you are replacing one layer of it.
• Ship a binary. Zero releases, zero assets. You build from source against a pinned Rust 1.97.1, or you use the Containerfile or Nix flake.
• Promise a stable shape. Pre-1.0 with an explicit no-compatibility rule means config keys, routes and proto fields can vanish in the change that replaces them.
• Work without an object store. There is an in-memory backend for tests, but the production story is S3 or GCS, and the design assumes their CAS and range-read semantics.
• Have a second maintainer, really. More on that below.

Bus factor, counted from the log

Across all 85 commits: Tobi Lütke under three separate git identities accounts for 55, or roughly 65%. Yad Konrad has 18. Ilya Grigorik has 5. The remaining five commits are one each from five different people. So the outside contribution is real but small, and the project is one person with a strong collaborator.

The mitigating fact is size. 68,562 lines with 88 dependencies is large for a weekend but small enough to fork and carry if the author loses interest, and MIT licensing means you can. That is a better position than depending on a 500,000-line forge.

Against the thing you would otherwise run

	walgit	Gitea
First commit	23 Aug 2026	1 Nov 2016
Stars	2,492	57,965
Release assets on latest tag	0	186
Durable state to operate	a bucket	database plus disk
Repo larger than the host's disk	a design goal	not the model
Issues, PRs, CI	none, by design	included

Read that table honestly and it says walgit is not a Gitea replacement. It is a replacement for the NFS mount or the replication layer underneath a forge, and the forge is still your problem.

Verdict

Nobody should put a team's repositories on a three-week-old git server with no releases and an explicit no-compatibility policy. That is not a criticism of the code, it is what pre-1.0 means, and the maintainers wrote it down rather than letting you discover it.

What we would do: clone it, read GOAL.md and AGENTS.md, and understand the CAS-manifest trick, because the constraint it answers (small ephemeral hosts, a repository larger than local disk, no coordination) is going to keep showing up. The star curve says a couple of thousand people reached the same conclusion in three weeks.

What would change our mind about running it: a tagged release with binaries, published results against that 57 GiB reference workload from someone who is not the author, and a second person with commit access who has been through the WAL. Two of those three are the kind of thing that can happen in a month.