git-fs-s3
An isomorphic-git filesystem backend for S3-compatible object storage — run git repositories on serverless platforms with no disk and no git binary.
isomorphic-git ──fs──► git-fs-s3 ──► ObjectStore ──► S3 / R2 / MinIO / memoryisomorphic-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/9de29bb2d1d6434b8b29ae775ad8c2e48c5391Extracted 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-s3The fs backend itself — createGitFs, object stores, caching, and retry.
git-fs-s3/httpA git smart-HTTP protocol handler (upload-pack / receive-pack) built on it.
git-fs-s3/opsHigher-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.