git-fs-s3

Run git repositories on serverless platforms — no disk, no git binary, and no state between invocations.

isomorphic-git  ──fs──►  git-fs-s3  ──►  ObjectStore  ──►  S3 / R2 / MinIO / memory

isomorphic-git removed the need for a native git binary, but it still expects a filesystem. On Lambda, Vercel, or Cloudflare Workers you don’t have a durable one. git-fs-s3 maps the filesystem contract git actually uses onto object-storage keys, so a bare repository lives entirely in a bucket:

repos/alice/blog/HEAD
repos/alice/blog/refs/heads/main
repos/alice/blog/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391

Extracted from the git layer of a production git-hosting service, where it serves clones, pushes, and repo browsing directly against Cloudflare R2 from Vercel functions. Use it to build git-backed CMSes, notes apps with real version history, lightweight code forges, or agent sandboxes with auditable file history.

Three layers, usable independently

git-fs-s3

The fs backend itself — createGitFs, object stores, caching, and retry.

git-fs-s3/http

A git smart-HTTP protocol handler (upload-pack / receive-pack) built on it.

git-fs-s3/ops

Higher-level git-hosting operations (branches, commits, diffs, history, merge) built on that.

Why this shape

No disk required

Every read and write goes straight to S3/R2 — nothing touches local disk, which is exactly what serverless platforms can’t reliably offer between invocations.

Production-tested

Extracted from a real git-hosting service’s git layer — the caching, retry, and repack logic exist because production traffic needed them, not as speculative design.

Composable stores

The whole backend is five methods (get/put/delete/head/list). Implement ObjectStore for anything — GCS, Azure Blob, a database — and every other piece keeps working.

Bring your own hosting

/http and /ops are framework-agnostic — plain functions over a Repo, Fetch-API-shaped in and out. Wire them into whatever router you already have.