git clone --depth=1 https://gitdelivr.net/github.com/torvalds/linux
The idea came from reading that GNOME had to redirect git clone traffic to GitHub mirrors because their GitLab bandwidth bill [1]. As a long time open source contributor and FOSS mirror hoster myself, it seemed surprising that this is a thing in 2026. We have jsDelivr for npm, and CDNs for Docker images and ML, but GNOME out of all projects has to move to use GitHub as a mirror.
Technically Git makes this surprisingly natural to cache as the same clone request produces the same packfile, so in my Workers code I hash the request body and use that as the cache key from R2. Refs get a short TTL of 60s.
The nice thing is you don't have to trust the proxy (I know the first question might be how do we trust you?) because git itself verifies every object hash client-side. And the source code is available on GitHub [2]. It's very light and turned out to be a weekend side project to help not just GNOME but anyone either facing a) egress bills b) not willing to move to GitHub or GitLab SaaS due to costs. It's 2026 so nobody should pay for egress if we have nice things like Cloudflare Workers + R2 :)
There's also support for Git LFS. Total cost to run is about $5/month.
I tested it with a dozen of different Git remotes: GitHub and GitLab of course but also, Codeberg, Gitea, and a few self-hosted instances.
This is meant to be used on public repos only, so private repos don't work but you can take the source code and adjust it and deploy it yourself.
If nobody uses it, it was a still fun project to see how far I can push Cloudflare's offerings. (long-time customer, but haven't really played around with Workers)
[1]: https://www.phoronix.com/news/GNOME-GitHub-GitLab-Redirect [2] https://github.com/emirb/gitdelivr.net
handstitched•1h ago
If I were to run 'git clone https://gitdelivr.net/$repoUrl` then I would also be getting the Git repository metadata through GitDelivr. You could return any valid git repo, eg. just add one commit on top of the real main with a malicious buildscript. I dont see how this security model works at all?
emirb•1h ago
Git hash checks protect object integrity, so GitDelivr can't silently corrupt a packfile without Git noticing, but that still doesn't make it fully trusted.
Yes the code could still lie about refs/HEAD and serve a different but internally valid history, and Git would accept it. The endgame here is if this is something Cloudflare would pick up (or any other big player) to offer it for free, then you'd trust it because it's a big name (and not a new domain bought yesterday after a weekend project heh)
So the accurate security model is a) GitDelivr preserves Git object integrity b) it does not by itself guarantee authenticity of refs in a way you can verify it c) in that sense it's as close to using any other HTTPS Git mirror or CDN?