The Problem

Git hosting breaks down at scale because packfiles are large binary blobs laid out for local reads, not network access. Every operation is a random walk over gigabytes, which is why NFS-backed repos fail at large hosts and why GitHub's Spokes requires strict replication with a database and three-phase commit. walgit targets the monorepo-on-small-machines case: repositories larger than the machine serving them.

What This Does

walgit is a Rust git server that treats an S3/GCS bucket as the source of truth and every local disk as a disposable cache. A push is written as an immutable object to the bucket, then made visible via a compare-and-swap on a tiny manifest — that CAS is the consensus mechanism, so no leader, no quorum, no database. Any instance can accept a push; two racing instances cannot both win.

The implementation adds three things on top of Cursor's Continuity architecture (documented verbatim in docs/reference/cursor-git-at-any-scale.md): a remote reader that serves refs and web pages via HTTP range requests when packs won't fit locally, a history pack that keeps commits/trees local while blobs stay in the bucket, and bundle-uri so fresh clones are static files served by the bucket or a CDN. The server also includes Git LFS, a JSON API with an SDK, per-repo push policy, webhooks, and a browsing UI.

How It Is Wired

Execution starts in crates/walgit-cli/src/bin/walgit.rs (and walgit-server.rs for the server binary). The CLI dispatches to serve.rs, which boots the HTTP server in crates/walgit-server/src/lib.rs. From there, requests flow through web/api.rs (JSON API), web/v1.rs (git smart HTTP), and smart.rs (protocol handling). The critical path for a push is: receive.rs in walgit-git ingests the pack, walgit-wal writes it to the bucket via store_proto.rs, and the CAS manifest update happens in walgit-store/src/coord.rs.

The widest blast radius is in walgit-store/src/coord.rs — it owns the CAS that is the entire consistency story. A bug there corrupts the source of truth. Second is walgit-wal/src/publish.rs, which controls visibility of new objects. The walgit-git/src/receive.rs path handles protocol correctness and has the most integration tests (10 test files under crates/walgit-git/tests/).

The web/ React frontend is separate; it talks to the JSON API in web/api.rs and the SDK in web/sdk/repos.ts. The walgit-proto crate generates protobuf types used by the store layer. Deployment is a single binary with compose.yaml and Containerfile for containerized runs.

How To Use It

The README documents the full flow. Setup is one binary pointed at a bucket:

cat > walgit.toml <<'EOF'
[server]
listen = "0.0.0.0:8080"
public_url = "https://git.example.com"
auto_create_on_push = true
[server.auth]
mode = "token"
anonymous_read = false
tokens = [{ principal = "me", token_env = "WALGIT_TOKEN_ME", write = true }]
[store]
backend = "s3"
bucket = "my-walgit"
[store.s3]
endpoint = "https://s3.us-east-1.amazonaws.com"
region = "us-east-1"
EOF

WALGIT_TOKEN_ME=$(openssl rand -hex 24) walgit serve --config walgit.toml

Build with cargo build --release (Rust toolchain pinned in rust-toolchain.toml, Nix flake and justfile also present). Example configs live at walgit.example.toml and walgit.standalone.toml.

Real-World Use

A team with a monorepo too large for any single CI runner's disk. Push to https://git.example.com/acme/app.git — the repo auto-creates. CI clones via bundle-uri, pulling a static file from the bucket or CDN instead of hitting the server. Multiple walgit instances behind a load balancer all serve the same repos with no coordination; kill them all and the bucket still holds everything.

Code Health & Issues

  • Med — No measured static analysis has run on this repo; the following comes from structure only. The walgit-server crate is large (30+ source files) and handles auth, TLS, LFS, SSE, and web UI — a wide surface for a single binary. Test coverage is strong (32 test files across all crates), CI exists (.github/workflows/pages.yml), and the license is present. The web/ frontend has its own pnpm-lock.yaml and lint config, suggesting a separate build pipeline from the Rust core.

The Bottom Line

A serious, well-architected implementation of a novel git hosting model. The CAS-in-object-storage design is genuinely simpler than Spokes-style replication, and the codebase shows real engineering discipline. It is early (0 stars, single maintainer), so treat it as a technology evaluation target rather than production infrastructure — but the design is sound enough to warrant that evaluation.