# Anubis: Proof-of-Work Bot Firewall for Self-Hosted Web Services

> Anubis is a lightweight MIT-licensed Go reverse proxy that sits in front of a web service and challenges incoming HTTP requests with a browser-side proof-of-work puzzle, filtering automated AI crawlers before they reach the upstream server. The README calls it a nuclear response, because it blocks all non-solving clients including some legitimate crawlers.

**TecharoHQ/anubis** — Weighs the soul of incoming HTTP requests to stop AI crawlers

- Repository: https://github.com/TecharoHQ/anubis
- Website: https://anubis.techaro.lol/
- Stars: 22,716 · Forks: 735
- Language: Go
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/techarohq-anubis

## What Anubis Solves and When to Use It

Anubis is a Web AI Firewall Utility, as the README describes it, that intercepts incoming HTTP connections and issues a challenge before forwarding the request to an upstream service. The intended problem is the flood of scraping requests from AI companies and data collectors that overwhelm small self-hosted services with traffic they cannot sustain.

The tool operates as a reverse proxy. Every incoming connection must pass a challenge before the upstream server sees it. Legitimate human browsers solve the challenge invisibly with JavaScript; automated scrapers that do not execute JavaScript, or that are not programmed to solve the specific challenge type, are blocked.

The README is explicit about scope: in most cases, Cloudflare is sufficient to protect an origin server. Anubis exists for operators who cannot or will not use Cloudflare, such as those running services on home servers, institutional networks, or systems where privacy concerns make routing through a commercial CDN unacceptable.

## The Challenge Mechanism and WebAssembly Architecture

The challenge delivered to connecting clients is implemented in WebAssembly. The repository contains a wasm/ directory with both a wasm/anubis module and several wasm/pow subdirectories, and the Cargo.toml at the root defines a Rust workspace with these as members. The Rust code is compiled to WebAssembly and embedded in the Go binary during the asset build step.

The overall build pipeline compiles Rust to WASM, generates a JavaScript fallback (wasm2js for browsers without native WASM support), and bundles the web assets. These are all run by the npm assets command defined in package.json, which calls go generate, then the WASM build scripts, then the web and xess build steps.

The go.mod file shows the Go dependencies include github.com/tetratelabs/wazero for WASM execution on the server side, github.com/google/cel-go for the CEL expression evaluator used in bot policy rules, github.com/redis/go-redis/v9 for optional Redis state sharing across multiple instances, and github.com/prometheus/client_golang for metrics exposure. The result is a single Go binary that serves challenges and proxies validated traffic.

## Building Anubis from Source

Building requires Go, npm, and a Rust toolchain for the WASM components. From the repository root, the Makefile provides a single build target:

```bash
make build
```

This runs `npm ci`, downloads Go module dependencies, runs `go generate`, compiles the WASM components, builds the web assets, and then compiles the two Go binaries:

```bash
go build -o ./var/anubis ./cmd/anubis
go build -o ./var/robots2policy ./cmd/robots2policy
```

The robots2policy binary converts a robots.txt file into an Anubis bot policy definition, which is a utility for operators who want to derive an allowlist from their existing robots.txt configuration. For development against a local upstream service, the dev command in package.json runs:

```bash
go run ./cmd/anubis --use-remote-address --target http://localhost:3000
```

This starts Anubis pointing at a locally running server on port 3000. The --use-remote-address flag tells Anubis to trust the connecting IP address directly rather than reading an X-Forwarded-For header.

## Bot Policy Configuration

Anubis uses policy definition files to control which bots are challenged, allowed, or blocked without a challenge. The README links to docs/docs/admin/policies.mdx for the full documentation. The project acknowledges that well-behaved crawlers, including the Internet Archive, are affected by the default challenge configuration.

The allowlist approach requires explicitly naming crawlers that should pass through. The robots2policy binary assists with this by converting a robots.txt file, which already lists bots by name, into a policy definition. The go.mod dependency on github.com/gaissmai/bart indicates IP prefix matching is used internally, and the CEL expression evaluator (google/cel-go) suggests that policy rules support conditional logic beyond simple name matching.

Prometheus metrics are exposed by the running Anubis server, allowing operators to observe challenge pass and fail rates over time.

## The Nuclear Option: What Anubis Blocks at What Cost

The README uses the phrase 'a bit of a nuclear response' to describe Anubis's behavior. This is accurate: any client that does not solve the proof-of-work challenge receives no content. That includes AI scrapers, but also feed readers that do not execute JavaScript, syndication crawlers, API clients, and smaller legitimate crawlers that the policy definitions have not explicitly allowed.

The Internet Archive (Wayback Machine) is named specifically in the README as a crawler that may be blocked. For operators running content they want archived, this is a concrete operational trade-off: protecting the server from AI scraping traffic also removes the service from automatic preservation.

For services that use webhook delivery (receiving POST requests from third-party services), the challenge requirement creates a compatibility problem. Webhook senders do not solve browser-based challenges, so they would be blocked. The README does not document how to handle webhook endpoints that must bypass the challenge.

## Anubis versus Cloudflare for Bot Protection

Cloudflare is a commercial CDN and DNS provider that offers bot protection as part of its service. The README explicitly recommends Cloudflare as the first option for most operators. The key differences between using Cloudflare and running Anubis are control, privacy, and dependency.

Cloudflare operates as a man-in-the-middle for all traffic to a domain, which means TLS termination happens at Cloudflare's edge and all traffic passes through their infrastructure. Operators with data residency requirements, privacy-sensitive content, or institutional policies against third-party CDNs cannot use Cloudflare. Anubis runs on the operator's own infrastructure and adds no external dependency.

The cost of that control is operational burden: building Anubis requires Go and Rust toolchains, maintaining the deployment means running an additional reverse proxy, and tuning the bot policy requires ongoing work as new scrapers appear. Cloudflare's bot management is continuously updated by the vendor without operator intervention.

For self-hosted community forums, open-source project documentation sites, and personal servers being hammered by AI scrapers, Anubis offers a path to relief without signing up for a commercial service.

## Conclusion

Anubis is appropriate for self-hosted communities, developer tools, and small web services that are being overwhelmed by AI scraper traffic and cannot or will not use Cloudflare as a shield. It is the wrong tool for any public service that depends on search engine indexing, the Internet Archive, or other automated clients, unless those bots are explicitly allowlisted in the policy definitions. Before deploying, verify your bot policy configuration at docs/docs/admin/policies.mdx to avoid blocking crawlers you depend on.

## FAQ

### What does Anubis do?

Anubis sits in front of a web server as a reverse proxy and challenges every incoming connection with a browser-side proof-of-work puzzle. Automated crawlers that do not solve the puzzle are blocked before they reach the upstream service.

### Does Anubis block Google and other search engines?

By default, any bot that does not solve the challenge is blocked. The README states that allowlisting specific bots, including the Internet Archive, requires explicitly adding them to bot policy definitions in the configuration. The robots2policy utility can help build that list from an existing robots.txt file.

### What programming language is Anubis written in?

The main Anubis binary is written in Go. The challenge puzzle that runs in the visitor's browser is implemented in Rust, compiled to WebAssembly, and embedded in the Go binary during the build process.

## Sources

- [Official documentation](https://anubis.techaro.lol/)
- [Official README](https://github.com/TecharoHQ/anubis#readme)
- [Project repository](https://github.com/TecharoHQ/anubis)
- [Release notes](https://github.com/TecharoHQ/anubis/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/techarohq-anubis