Anubis Crosses 20,000 Stars: What Self-Hosting Your Own AI-Scraper Defense Actually Costs

Cloudflare's network sees more than 50 billion requests a day from AI crawlers — roughly 1% of all traffic it processes. Fastly has clocked individual sites getting hit 39,000 times a minute by scraper bots. If your site sits behind Vercel or a Cloudflare-fronted PaaS, some flavor of bot mitigation is bundled into the plan you're already paying for. If it sits on a Hetzner box you provisioned yourself, it has exactly zero bot defense by default — and the traffic doesn't care which one you picked.

Doing nothing about it has a real price tag, too: sites getting scraped without any defense report AI-crawler bandwidth running $1,000–$10,000 a month once traffic reaches the 1–10 TB/month range that a popular self-hosted project's docs or release mirrors routinely see — bandwidth and CPU cycles a hosting bill charges for, that nobody on the other end is paying you back for.

That gap is why Anubis, a Go reverse proxy that makes every suspicious request solve a small proof-of-work puzzle before it reaches your origin, went from a joke side project to protecting Codeberg, FFmpeg's mirrors, GNOME's GitLab, and the United Nations in about two years. It crossed 17,000 GitHub stars in February 2026 and has kept climbing since, past 19,000 by early 2026 and reportedly over 20,000 a few months later. Here's the number that actually matters if you're deciding whether to run it yourself: on a single CPU core, Anubis computes its challenge in under 3 milliseconds and filters upward of 10,000 requests per second, and the whole process fits in roughly 128 MB of RAM. Self-hosting your own bot defense is not, on the compute side, an expensive problem. The cost it does have is a different one, and it's the part vendors don't put in the pitch deck.

What Anubis Actually Does​

Anubis sits as a reverse proxy between your existing proxy (nginx, Caddy) and the application behind it — one instance per protected service, unless you chain two Caddy instances to share a single Anubis across several backends. When a request looks like a browser, Anubis serves a JavaScript challenge inspired by Hashcash: the client has to find an input that hashes (SHA-256) to a value below a target threshold, which costs real but small CPU time on a real browser and meaningfully more on a scripted one running thousands of requests in a batch. Pass the challenge, get a signed cookie, browse normally until it expires.

The numbers Techaro (the company behind it) publishes hold up in independent write-ups: the challenge computes in under 3ms, a single core clears 10,000+ RPS, and a 1GB VPS can push 15,000 RPS of filtering. Reported pass/block rates land around 98% of real human browsers getting through versus roughly 95% of headless scrapers getting stopped, and an offline honeypot layer — link-ordering entropy embedded in static HTML — catches an additional ~70% of stealth bots that skip JavaScript entirely. None of that is exotic; it's a Go binary doing arithmetic, which is exactly why the resource bill is so small.

It's worth placing Anubis on a spectrum rather than treating it as the only option. Drew DeVault deployed it on SourceHut, then a month later switched to go-away, a lighter-weight challenge tool he described as the "non-nuclear" alternative — useful context for anyone who assumes PoW is the only lever. Nepenthes sits at the opposite end: instead of blocking bots, it traps them in an infinite maze of generated nonsense text, wasting their compute rather than turning them away at the door. Anubis is the middle option — heavier than go-away, more confrontational than a tarpit, and the one that's actually crossed 20,000 stars.

The Real Cost of Standing It Up Yourself​

Here's the comparison that matters if your platform is a Cluster-API-managed fleet on owned Hetzner nodes rather than a hosted PaaS with an edge network bundled in:

The honest takeaway: the compute and dollar cost of running Anubis yourself is close to a rounding error. A CX22 that already runs three other tenant apps absorbs it without a second node. The real setup cost is the one line item that doesn't fit in a pricing table — deciding which routes get challenged and which don't, so your own webhook receivers, health checks, and API clients don't get served a JavaScript puzzle they can't solve.

That's not a hypothetical edge case; it's the default failure mode of an unconfigured deployment. A Stripe webhook, a GitHub Actions callback, or a health-check probe hitting /healthz every few seconds all look, to a proxy with no exemption rules, exactly like the browser traffic Anubis is designed to challenge — except these clients can't run JavaScript or solve a SHA-256 puzzle, so they simply fail. Getting this right means an explicit allowlist (by path, user agent, or source IP) carved out before the challenge layer goes live, not discovered after a payment webhook silently stops arriving.

The Tradeoff the Pitch Deck Skips​

Here's the part that doesn't show up in the RPS benchmarks: Anubis's original design required JavaScript, full stop, and that decision had real casualties. LWN — a site whose whole audience skews toward people who deliberately run lean, JS-disabled browsers — evaluated Anubis and declined to deploy it specifically because it locked out visitors who'd turned JavaScript off. The GitHub issue tracker fills up with the same complaint from screen-reader users and people on old or low-power hardware, where the proof-of-work computation isn't imperceptible — it's a real, sometimes battery-draining wait.

Techaro's response took until version 1.20.0: a Meta Refresh challenge that works without client-side JavaScript, added specifically to answer this criticism. That's roughly a year of shipped software where "install Anubis" meant "some real fraction of your legitimate human visitors, not just scraper bots, get turned away at the door." Bot-score-driven approaches from a managed vendor absorb that false-positive tuning as part of what you're paying for; a self-hosted PoW challenge pushes the decision — and the ongoing maintenance of that decision as your traffic shape changes — onto whoever runs the fleet.

Anubis's own honeypot layer is the more interesting long-term answer to this tension, because it doesn't force every visitor through a compute challenge at all: static HTML pages get a maze of invisible links ordered with enough entropy that a scraper following every link on the page trips it, while a normal browser rendering the page visually never sees or clicks them. That catches roughly 70% of stealth bots that skip JavaScript entirely — without a single legitimate visitor, JS-enabled or not, ever hitting a wait screen. It's a reminder that "self-hosted bot defense" isn't a single lever; it's a stack of mechanisms with different accuracy-versus-friction tradeoffs, and the PoW challenge is the blunt, visible one that gets the GitHub stars.

Does a Self-Hosted PaaS Need This Bundled?​

Put the two costs side by side and they don't weigh the same. The compute cost of running your own bot defense is genuinely close to free — 128 MB of RAM and a fraction of a CPU core is not a reason to skip it. The accessibility cost is real, ongoing, and platform-specific: it depends on who your tenants' actual visitors are, whether their apps serve API clients that can't solve a JS challenge, and how much false-positive risk they're willing to accept in exchange for cutting scraper load.

That asymmetry is the argument for shipping a PoW-style layer as an opt-in primitive at the Gateway API level rather than a default-on toggle — the same way TLS via ACME ships automated because there's no real tradeoff to disclose, while a bot-defense layer ships as a flag a tenant flips deliberately, because turning it on changes who can reach their app. A self-hosted PaaS that owns its own ingress is well positioned to make that an honest one-line config choice instead of leaving "go figure out Anubis yourself" as tenant homework — it just shouldn't pretend the accessibility tradeoff doesn't exist by turning it on for everyone by default.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. An opt-in bot-defense primitive at the Gateway API layer is the kind of platform choice that stays honest about its tradeoffs instead of hiding them behind a toggle. Star the repo on GitHub or deploy your first app today.

Sources​

• GitHub - TecharoHQ/anubis
• Anubis: Open-source web AI firewall to protect from scraper bots - Help Net Security
• Anubis (software) - Wikipedia)
• Anubis: How the Viral AI Scraper Firewall Actually Works - WebDecoy
• Anubis - Best AI Bot Protection for Self-Hosted Site Operators in 2026 - toolhunter.cc
• Anubis sends AI scraperbots to a well-deserved fate - LWN.net
• Anubis: Fighting off the hordes of LLM bot crawlers - The Register
• Fastly warns AI bots can hit sites 39K times per minute - The Register
• Support non JS users · Issue #95 · TecharoHQ/anubis
• Anubis, tool to stop "AI" crawler abuse, gains non-JavaScript option - OSnews
• Deploying Anubis on nginx - blueslugs.com
• Anubis + Caddy - SIMPLICY.INFO
• Cloudflare Bot Management
• Get started with Bot Fight Mode - Cloudflare docs
• How to block and confuse AI crawlers with nepenthes and fail2ban - petermolnar.net
• The Economics of AI Web Crawling in 2026 - DEV Community

All figures cited above are drawn directly from the linked sources.