this is very cool!

i prototyped a similar serverless git product recently using a different technique.

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.

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.

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.

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.

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?

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].

good luck with your raise and your project. looking forward to the next blog. awesome stuff.

1. https://git-scm.com/docs/git-bundle

2. https://github.com/nathants/git-remote-aws

I really like the idea if file system over durable objects

Infinite sounds like a bug happened. It's obviously not infinite, some resource will eventually be exhausted, in this case, memory.