hraness

saved

walgit: one binary in front of an object store

by Tobias LütkeGitHub

gist

walgit is a single Rust binary that hosts Git in front of S3 or GCS, with no database, no leader, and no local state that matters. It implements Cursor's Continuity architecture: a write-ahead log in object storage is the source of truth, and every machine is a disposable cache. A push is visible only after a compare-and-swap on a tiny manifest. For monorepos larger than the host, it adds a remote reader, a local history pack of commits and trees, and bundle-uri clones served as static files.

ideas

  • The bucket is the repository. Every walgit process is a disposable cache; kill them all and you lose warmth, nothing else.
  • CAS on the manifest is consensus. A push uploads an immutable object and becomes visible only when a tiny manifest is rewritten with compare-and-swap; racing instances cannot both win.
  • Continuity, then small machines. The README takes Cursor's WAL-in-object-storage design as-is, then adds a remote reader, a history pack, and bundle-uri so a monorepo can exceed the host.
  • Reads revalidate first. Every read starts with a conditional GET of the manifest; 304 serves the local copy, 200 applies new log entries.
  • Placement is configured, never inferred. Refs-level reads work everywhere; object work only where placement globs assign it.

quotes

walgit hosts git repositories with no database, no leader and no local state that matters.

Tobias Lütke, stating the deployment thesis.

Every machine that runs walgit is a disposable cache; the bucket is the repository.

Tobias Lütke, naming the cache versus source-of-truth split.

That CAS is the consensus — no election, no quorum, no primary.

Tobias Lütke, explaining how compare-and-swap replaces a leader.

The manifest CAS is the only commit point; everything before it is invisible, everything after it is idempotent and replayable.

Tobias Lütke, stating the visibility and replay invariant.