Bots are Ruining Git Hosting — Here's a Smarter Fix

Let's not pretend the internet has a bot problem. It has a bot crisis. Scrapers, crawlers, and every shade of automated nonsense hammer servers relentlessly, and Git hosting providers have been drowning in the noise just like everyone else. The standard playbook? Deploy something like Anubis, which throws a proof-of-work gauntlet at visitors. Does it work? Barely. Is it a terrible experience for everyone involved? Absolutely.

Proof-of-Work is Basically Medieval Punishment

Here's the deal with proof-of-work systems: they make your computer sweat through complex puzzles before you can see anything. It's the same energy-hungry nonsense that Bitcoin and Ethereum get dragged for constantly — computational effort that vanishes the instant it's done. For a developer just trying to peek at a repo or grab some code, watching your browser grind through math feels like being punished for having a pulse.

We've spent years squeezing every millisecond out of web performance. Latency gets optimized to the bone. Connections get pipelined and multiplexed within an inch of their lives. And then we deliberately slam artificial delays into the pipeline because some bot is being annoying? That's not a solution — that's throwing the baby out with the bathwater.

Flipping the Entire Model

This is where the "do-the-work" idea gets interesting. It completely inverts how client-server relationships usually work. Instead of the server grinding away while clients sit pretty, the client actually covers the computational cost of getting what it needs.

This sounds wild until you realize how Git actually works. Git is built from simple objects — commits, trees, blobs, tags. Everything you see in a repository viewer is just a formula away from these building blocks. Get the objects, and you've got everything. The data you want isn't locked behind server-side processing — it's sitting there, waiting.

A Git Viewer That Lives in Your Browser

Here's where it gets clever. Browsers today are ridiculously capable. A developer built a fully client-side Git repository viewer that runs entirely in the browser. The server's only job? Serving static files — plain old bare repositories over HTTP. No CGI scripts, no database backend, no complex machinery. Just a basic web server with some rewrite rules.

The browser grabs objects on demand, stuffs them into IndexedDB for caching, and calculates diffs, file contents, and commit history right there. It's essentially running a partial git clone in your browser, fetching objects as you navigate around. The server just sits there and hands over files. That's it.

Why This Changes the Game for Developers

For startups and smaller dev shops, this approach brings some real advantages to the table:

Bandwidth is suddenly your only bottleneck. Since you're serving plain static files, you can shove a CDN in front of everything without any special configuration. Your repository viewer becomes practically infinitely scalable with almost zero backend complexity to maintain.

Privacy improves automatically. Once your browser caches those objects, return visits don't need to fetch anything if nothing changed. After the first load, you could browse a repository completely offline. No server logging every page you visit, no tracking through pagination requests.

Deployment becomes embarrassingly simple. Static hosting works everywhere. GitHub Pages, Netlify, Cloudflare Pages, even a basic object storage bucket. Your viewer becomes infrastructure that practically manages itself.

The AI Development Angle

This gets especially interesting as AI-assisted coding tools become the norm. More code gets generated, more repos get created, and demand for lightweight hosting solutions keeps climbing. Systems like this hint at a future where your development infrastructure doesn't need to be a heavyweight managed service — it can be lean, static, and surprisingly capable.

The compute sitting in users' browsers is essentially free processing power you can leverage. Instead of paying through the nose for server-side rendering, you're harvesting client-side computation. For high-traffic public repositories, this could mean serious cost savings.

Is This Actually the Future?

Let's be real — it's still early. Think of this as a proof-of-concept that demonstrates what's possible rather than a turnkey solution ready for prime time. But the underlying principle holds up: push work to the client, keep the server lightweight.

For Git hosting specifically, if you don't need the full platform experience — issues, pull requests, CI/CD pipelines — and you just want to browse code, this approach could replace heavyweight solutions like cgit with something far more scalable and privacy-conscious.

Next time you're figuring out how to protect your services from scrapers without making life harder for real users, think about the do-the-work approach. Your users' browsers have idle cycles. Your servers have limited resources. Let the browsers do the math.

Sometimes the best answer to a scaling problem isn't throwing more server power at it — it's distributing the work to where compute already exists waiting to be used.