Dora NodaA veteran Linux developer shut down his public git server after running it since 2011, titled the eulogy "Thank you, AI," and watched it climb to 298 points on Hacker News. If you self-host anything, that headline lands like a warning shot: is this the moment the self-hosting story breaks? Here is the verdict before the why: no — but the casualty is real, and it is specifically the solo-public service. A one-person public forge cannot win the AI scraper war, and it cannot match the agent workflows concentrating on hosted forges. A team-scale forge on an owned fleet, with shared bot defenses and self-hosted CI runners, is unaffected provided it actually builds those two things. The rest of this post shows the evidence, then gives you the keep/move/hedge framework for your own machines.
| Your service | Verdict | Why |
|---|---|---|
| Solo-public forge, wiki, or cgit box | Move to a hosted forge | One person cannot staff the scraper war; mirrors were already the primary |
| Team forge + CI on an owned fleet | Keep, with conditions | Forgejo + self-hosted runners + shared bot defense answers both pressures |
| Public mirrors, caches, registries | Hedge — keep the copy, cede the front door | Cheap to keep, expensive to defend; let the host absorb the bots |
The eulogy, and what it actually says
Get the facts straight first, because this story is already being retold wrong. The author is Gerd Hoffmann, a QEMU, firmware, and Linux developer blogging at kraxel.org. His post "Thank you, AI" went up on January 26, 2026; the Hacker News thread "End of an era for me: no more self-hosted git" ran in February 2026 and reached 298 points with 211 comments. He had a public git server running since 2011 (~15 years), with a public CVS server before that in an era the post does not date — so "fifteen years of git" is the verified tenure, and anything rounder is embroidery.
And the stated reason is not what the retellings claim. He did not leave for better review tooling, CI integrations, or agent workflows. His words: AI scrapers had "hammered the poor, little server to death by flooding the cgit frontend with tons of pointless requests" months earlier, and he decided not to rebuild — "I don't feel like taking up the fight with the scrapers in my spare time, I leave that to people who are in a better position to do so." Most repositories already had mirrors on GitLab or GitHub; those mirrors are now simply the primary copies. He fixed the dangling links and moved on.
The coda is the bleakest part, and the most instructive. Even after the shutdown, the bots kept coming: millions of requests for a cgit service that no longer existed, each answered with a 404 that Apache served happily while the logs filled the disk faster than logrotate's default configuration could keep up. He fixed the logrotate config and hoped the siege would notice the surrender. It will not — the scrapers do not check whether you gave up. Any honest steelman of this exit starts there — not with workflow gravity, but with a siege engine that does not stop when you open the gates.
Pressure #1: the scraper war a solo box can't win
Kraxel's box was not unlucky; it was typical. The AI scraping wave of 2025–2026 hit public FOSS infrastructure as a distributed denial-of-service that looks nothing like an attack and everything like popularity. The numbers from the projects big enough to measure it are stark:
- kernel.org fields roughly 6 million requests a day for individual commit pages on git.kernel.org, and spends about 20% of its total CPU serving automated scrapers. Konstantin Ryabitsev, who runs the infrastructure, estimates legitimate requests are only about 2% of the traffic — everything else is bots.
- The project's shield is Anubis, a proof-of-work challenge in the Hashcash tradition: prove you spent CPU before you get a page. It bats away about two-thirds of the scraper traffic — and the remaining third now solves the challenge anyway, because kernel commit history as pristine training data is worth burning compute to reach.
- Fedora's infrastructure has been knocked offline for weeks at a time. In March 2025, aggressive scrapers disrupted KDE's GitLab, with similar incidents reported against GNOME, SourceHut, and others.
Notice the shape of this problem. It is not "configure rate limiting once" — it is an arms race with well-funded adversaries who adapt to each defense, and the defense itself (proof-of-work challenges, log pipeline hardening, capacity headroom) is ongoing operational labor. A kernel.org or a Fedora can staff it. A solo maintainer with a cgit box and a day job cannot, and the rational move is exactly what kraxel did: cede the front door to organizations "in a better position" to fight. This is the first AI-era change to the self-hosting calculus, and it is defensive, not aspirational: the cost of being publicly crawlable went from near-zero to a part-time security job.
Pressure #2: the workflow gravity nobody stated but everybody feels
Now steelman the exit one step further than its author did — because the retellings, wrong about his reason, are right that a second pressure exists. The agentic coding workflow of 2026 genuinely lives on hosted forges, and a solo self-hosted setup genuinely cannot follow it there.
The numbers first: JetBrains' January 2026 developer survey found 68% of professional developers now use an AI coding assistant daily, up from 44% in 2024. The workflow has moved past autocomplete into delegation — GitHub's coding agent is assigned work through GitHub Issues, then operates inside a GitHub Actions environment: reading the codebase, making changes, running tests, opening pull requests, and responding to reviewer comments. Cursor runs cloud agents on its own compute. The emerging default in mid-to-large teams is the agent-review loop — agent codes, human reviews, agent fixes — and every step of that loop is PR-native on the hosted forge.
A solo self-hosted cgit box participates in none of this. No issue-assigned agents, no review bots commenting on diffs, no managed Actions minutes, no ecosystem of CI integrations one click away. Could a determined solo operator wire equivalents together? In principle — webhooks and APIs exist. In practice, the network effect is the product: the agents go where the repos already are, the integrations target the forges with the users, and each quarter the gap compounds. This pressure, unlike the scraper war, is not hostile. It is just gravity. And it means the honest 2026 case for keeping a solo-public forge has to answer not one question ("can you keep the bots out?") but two ("and can you match a workflow your collaborators get for free elsewhere?").
What stops being true with a team and a platform
Here is where the exit stops generalizing — because every pressure above has "solo" or "one box" baked into it. Put a team and a real platform underneath the same services and each conceded point gets an answer. The table below maps them one by one, with the condition each answer requires.
| Conceded pressure | Self-hosted answer on an owned fleet | Condition |
|---|---|---|
| Scrapers kill the public web frontend | Shared bot defense (Anubis-style proof-of-work, hardened log pipelines) amortized across every service on the fleet | The platform team actually runs it once, centrally — not per-service folklore |
| No managed CI minutes | Forgejo Actions with self-hosted runners on your own machines | Runners live on the fleet with real isolation; hosted-forge overflow is the fallback, not the plan |
| No agent/review ecosystem | API-compatible forge (Forgejo speaks the Gitea API surface) plus self-hosted review bots and MCP tooling pointed at your own repos | Someone wires the webhooks once; agents follow APIs, not brands |
| Mirrors already the de facto primary | Keep the mirrors — as a hedge, not a surrender | Push mirrors stay automated so the hosted copy is always a fallback, never the only copy |
| One person's spare time | Platform labor is pooled: N services share one defense and one runner pool | The fleet exists — this entire column assumes owned machines under central management |
The tooling side of this column is in better shape in 2026 than most hosted-forge defaulters assume. Forgejo has become the community default recommendation — nonprofit governance under Codeberg e.V., GPL licensing, monthly security backports, and Forgejo Actions runners with saner security defaults than their Gitea equivalents. Codeberg's own hosted runners are deliberately limited (a nonprofit cannot fund everyone's CI), which tells you the intended shape outright: the forge can live anywhere, but serious teams self-host the runners — typically a container pair next to the forge, registered with a token, running GitHub-Actions-syntax workflows. Federation across instances is in progress. None of this helps a solo cgit box. All of it works the moment "the platform" is a thing that exists.
Note what this table does not claim. It does not claim self-hosting matches hosted-forge workflow gravity feature for feature — it claims the gap is bridgeable labor, not physics, once labor is pooled. A team that will not staff the middle column should move, not keep. The framework below makes that explicit.
The decision framework: keep, move, or hedge
Classify each public service you run on two axes: who absorbs the scraper war, and where the workflow gravity pulls your collaborators. Three buckets cover nearly everything, with forge and non-forge examples each:
Move — the solo-public front door. If a service is public, maintained by one person in spare time, and its audience already lives on a hosted platform, move it. The solo-public forge is the canonical case: kraxel's repos already had GitLab/GitHub mirrors, so the move cost was link fixes. Same logic applies to a personal wiki indexed by bots, a public pastebin, or a vanity package registry with three users. You are not surrendering self-hosting; you are refusing a second unpaid job as a bot-war combatant.
Keep — the team service on a real platform. If the service backs a team workflow and the fleet already amortizes defense and compute, keep it — and fund the middle column of the table above honestly. Team forge plus self-hosted CI runners is the canonical case. Non-forge keeps: self-hosted CI runners even for repos hosted elsewhere (your compute, your cache, your secrets boundary), private repositories with no public frontend to defend, and internal registries and artifact stores behind authentication, where scrapers never reach and gravity does not apply.
Hedge — the cheap copy, not the defended front door. If a service is cheap to replicate but expensive to defend, keep a copy you control and let someone else's infrastructure absorb the bots. Push mirrors of every repo to a hosted forge (automated, always current) is the canonical case. Non-forge hedges: a container image mirror you can pull from when the registry is down, a static export of documentation served from cheap object storage while the canonical docs live wherever collaborators edit them, and release artifacts attached in two places. The hedge costs nearly nothing until the day it saves you.
Run your own inventory through those buckets this week. Most solo operators will find one or two "move" candidates they have been defending out of inertia — and most teams will find a "keep" they underfunded because nobody priced the bot defense it quietly needs.
Conclusion: the casualty is solo-public, not self-hosting
Kraxel's eulogy deserves its 298 points, but read it as written: a solo operator declining a fight he could not staff, executed cleanly because mirrors already existed. The AI era changed the self-hosting calculus twice over — first by turning public crawlability into an ongoing siege, then by concentrating agentic workflows where the repos already are — and both changes land hardest on exactly one shape of service: public, solo, and defended in spare time. That shape should move, without shame. Everything with a team and a platform underneath answers both pressures with pooled labor and owned machines, on the condition that the labor is actually pooled. The question for your fleet was never "self-host or surrender." It is which bucket each service belongs in — and whether the keeps are funded like it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
