The bucket is the repository, and every server is a cache
walgit changes the usual Git hosting layout. Repository state lives in an object-store write-ahead log, while files on each server can be rebuilt and discarded. A tiny manifest is updated with compare-and-swap and acts as the commit point. Immutable pack and log objects sit behind it. Any instance may accept a push, and racing writers must re-read and retry when only one manifest update wins. The design removes a leader and repository-placement database from the serving path.
The server exposes smart HTTP v0 and v2 for fetch and push, Git LFS, bundle URI clones, a React repository browser, a JSON API, push policies, and webhooks. It supports SHA-1 and SHA-256 repositories. Fresh clones can download scheduled bundles directly from object storage or a CDN, leaving the server to supply only the remainder. For very large repositories, a remote reader uses HTTP range requests so packs need not fit on the machine.
Large repositories gain more than a stateless HTTP tier
Moving files to S3 is only the first layer. Git pack access is random and can turn a network filesystem into a latency problem. walgit keeps commits and trees in a history pack while allowing blobs to remain remote, then uses checkpoints and immutable log entries to rebuild state. Maintenance work such as compaction, bundle creation, connectivity audits, and repairs is derived from the durable log rather than a separate job database.
That model fits a narrow buyer. A company with a monorepo larger than its serving machines, expensive clone traffic, and existing object-store operations has reasons to test it. A team hosting 40 ordinary repositories does not. It would be adopting new storage semantics, cache placement, leases, compaction, and recovery behavior to solve a scale problem it lacks. The README is unusually candid about round trips to the bucket being the cost budget.
What happened when we ran it
Our sandbox cloned commit a71c592, a 3.4 MB checkout with 212 files and about 74,266 source lines. Installation succeeded in 25 seconds and installed 658 packages. The repository had 1 CI workflow, a compose file, and a tests directory. The lab found no Dockerfile, while the README documents a separately named Containerfile, a Nix package, and a local object-store development path.
The build ran for 643 seconds and failed with exit 101. The tail reported 3 errors in walgit-server, including Rust diagnostics E0277 and E0433. One compiler suggestion said to remove an .await, and the complete expanded type was written to a file inside the build directory. The log tail does not provide enough context to state which dependency, feature, or source change caused those errors.
Tests ran for 271 seconds and failed with exit 101 while compiling walgit-server and its library test target. The output again showed E0277, suggested removing an .await, and said the library could not compile. No test result followed because compilation did not finish. This is a build failure in our measured commit, not evidence that a particular Git protocol case or storage invariant failed at runtime.
One binary still needs an object store and identity plan
The opening configuration is short: listen address, public URL, authentication mode, bucket, and store endpoint. Real operation adds more decisions. Static tokens can come from environment variables, while OIDC supports providers such as Google, Entra, Okta, Auth0, Keycloak, Dex, and GitLab. The server issues its own access tokens after browser login. Rotating the session secret revokes those tokens, which must be part of an operator's incident plan.
Roles can be split into serving, maintenance, and event delivery. Multiple serving hosts can share one bucket, but each repository should have one maintainer selected through placement rules. Bundle schedules, compaction, cache mode, webhook cursors, TLS, and CDN or nginx byte offload all need configuration. The single binary reduces application packaging; it does not remove storage credentials, monitoring, routing, or recovery testing.
It is a Git server, not a collaboration forge
The web interface browses trees, blobs, commits, diffs, and WAL health. Per-repository policy can protect refs, require fast-forward updates, and assign groups or bypass lists. What the README does not offer is equally important: there is no issue tracker, pull-request review system, CI product, package registry, or organization administration comparable to a full forge. Those omissions are reasonable for the architecture, but they change the buying decision.
Project activity is immediate and early. The last push was 2026-08-25, GitHub showed 5 open issues and pull requests combined, and no release was published. Current pull requests covered storage coordination, browser authentication, webhook batching, protected namespaces, and another blob backend. This is evidence that the core is moving, not that those changes have settled into a stable release line.
walgit is best read as a serious implementation of an object-store-native Git architecture. Its documentation provides enough detail for an infrastructure team to review the invariants before a trial. The failed 643-second build raises the bar for that trial: pin the commit, reproduce compilation, then test push races, cold reads, recovery, and bucket behavior with disposable repositories. Conventional teams should take the simpler answer and install a conventional forge.