this is very cool!<p>i prototyped a similar serverless git product recently using a different technique.<p>i used aws lambda holding leases in dynamo backed by s3. i zipped git binaries into the lambda and invoked them directly. i used shallow clone style repos stored in chunks in s3, that could be merged as needed in lambda /tmp.<p>lambda was nice because for cpu heavy ops like merging many shallow clones, i could do that in a larger cpu lambda, and cache the result.<p>other constraints were similar to what is described here. mainly that an individual push/pull cannot exceed the api gateway max payload size, a few MB.<p>i looked at isomorphic, but did not try emscripten libgit2. using cloudflare is nice because of free egress, which opens up many new use cases that don’t make sense on $0.10/GB egress.<p>i ended up shelving this while i build a different product. glad to see others pursuing the same thing, serverless git is an obvious win! do you back your repos with r2?<p>for my own git usage, what i ended up building was a trustless git system backed by dynamo and s3 directly. this removes the push/pull size limit, and makes storage trustless. this uses git functionality i had no idea about prior, git bundle and unbundle[1]. they are used for transfer of git objects without a server, serverless git! this one i published[2].<p>good luck with your raise and your project. looking forward to the next blog. awesome stuff.<p>1. <a href="https://git-scm.com/docs/git-bundle" rel="nofollow">https://git-scm.com/docs/git-bundle</a><p>2. <a href="https://github.com/nathants/git-remote-aws">https://github.com/nathants/git-remote-aws</a>