Skip to content

CONCEPT Cited by 1 source

Wasm Git server

Wasm Git server names the implementation shape in which the server side of the Git smart-HTTP protocol runs as a WebAssembly module inside a serverless / edge runtime, rather than as a native binary on a dedicated host. Introduced to the wiki by Cloudflare's 2026-04-16 Artifacts launch — a ~100 KB pure-Zig Wasm binary with zero dependencies beyond Zig's std that implements the Git protocol end-to-end from scratch.

Why build a Git server in Wasm

Not the traditional deployment:

  • Git servers have historically been native binaries (git-daemon, git-http-backend) or large Python / Ruby apps (GitLab, Gitea, GitHub's Rails app) on dedicated hosts.
  • Wasm reframes the question: "can we embed a Git server inside each serverless request?"
  • The answer matters when the server's substrate is a [[systems/ cloudflare-durable-objects|Durable Object]] with a ~128 MB memory budget and ~10 ms cold-start expectations — you can't boot GitLab inside that envelope, but you can load a 100 KB Wasm module.

Cloudflare's three stated reasons in the Artifacts post:

  1. Binary size discipline. "The entire git protocol engine is written in pure Zig (no libc), compiled to a ~100KB WASM binary (with room for optimization!). It implements SHA-1, zlib inflate/deflate, delta encoding/decoding, pack parsing, and the full git smart HTTP protocol — all from scratch, with zero external dependencies other than the standard library."
  2. Memory control. "Zig gives us manual control over memory allocation which is important in constrained environments like Durable Objects."
  3. Testability via dual compilation. "The Zig Build System lets us easily share code between the WASM runtime (production) and native builds (testing against libgit2 for correctness verification)." Conformance tests against real Git clients; verification tests against a libgit2 server as an oracle.

Host interface — a thin JS ↔ Wasm boundary

From the post: "The WASM module communicates with the JS host via a thin callback interface: 11 host-imported functions for storage operations (host_get_object, host_put_object, etc.) and one for streaming output (host_emit_bytes). The WASM side is fully testable in isolation."

Why this matters: the narrower the host interface, the easier the Wasm side is to fuzz / conformance-test / swap implementations of. Twelve functions is a small enough surface to mock exhaustively; the Wasm side can run against an in-memory storage mock without a live DO at all.

Protocol coverage

Artifacts' Zig engine supports both v1 and v2 of the Git smart-HTTP protocol, including:

  • ls-refs for listing remote refs without a full clone.
  • Shallow clones: deepen, deepen-since, deepen-relative.
  • Incremental fetch with have / want negotiation.

This is enough for real-world Git clients to interoperate without knowing they're talking to a Wasm server. From-scratch in Zig: SHA-1, zlib inflate/deflate, delta encoding/decoding, pack parsing.

Why Zig

Zig specifically — rather than Rust / C++ — because:

  • Manual allocator control fits the DO memory budget.
  • Zig's Build System makes dual-target compilation (Wasm for prod + native for tests-against-libgit2) a first-class build configuration, not an afterthought.
  • No libc dependency keeps the binary small and the host interface minimal.

Not a claim that Rust / C couldn't do this — a claim that Zig's specific ergonomics around memory control + cross-compilation paid off for this workload.

Generalisation

Applies whenever:

  • A network protocol has an entrenched client base you can't ask to change.
  • The server side needs to run inside a serverless / edge runtime with tight memory + cold-start budgets.
  • One instance per resource is the economic model (millions of Git repos → millions of DOs → each needs its own Git server instance; a per-DO 100 KB Wasm module is viable, a per-DO Rails app is not).

Other candidates where the shape might transfer: SSH (Wasm server for Git-over-SSH or config protocols), NFS / SMB subsets, BGP listeners, Kafka producer/consumer protocols, database-protocol edge proxies.

Trade-offs

  • ✅ Small attack surface (narrow host interface, no libc).
  • ✅ Portable, deterministic execution (Wasm).
  • ✅ Testable in isolation.
  • ⚠️ Rebuilds protocol state machinery from scratch ("SHA-1, zlib, delta encoding/decoding, pack parsing" — considerable engineering effort; no reuse of libgit2 / go-git / JGit).
  • ⚠️ Engineering-team depth requirement: protocol-level Git is not a casual implementation target; Cloudflare has the relevant depth.
  • ⚠️ Feature-parity drift risk with upstream Git's ongoing protocol evolution (SHA-256 hash transition, bundle-URI, reftable, etc.).

Seen in

Last updated · 200 distilled / 1,178 read