Anubis explained: policies and proof of work for self-hosted websites

Anubis is an open-source web protection proxy placed before an origin. It makes high-volume automated clients spend computation while policy-approved visitors proceed. At capture time it had 20,826 stars, about 23 default-branch commits in 30 days, and release v1.25.0. Interest is tied to pressure from AI dataset scraping, yet the maintainers describe the approach as a high-friction response rather than a default installation.

It can protect documentation, code hosting, personal services, and public communities whose CPU, bandwidth, or database connections are exhausted by bot surges. Ordered policies allow, deny, challenge, or add weight to a request, with rules for known bots and custom paths. A client that passes the challenge receives a signed access credential. Prometheus metrics expose challenges, failures, policy matches, and request behavior.

A request first passes through ordered policy rules. ALLOW proceeds, DENY rejects, CHALLENGE starts verification, and WEIGH changes later difficulty. The challenge page calculates a browser result matching a target; the server verifies it cheaply and issues a time-limited credential. This moves cumulative scraping cost toward clients, but it does not establish a visitor’s identity and does not guarantee that capable automation cannot solve the work.

The main service is written in Go, the challenge interface uses Preact, and policies are configured in YAML. Access credentials involve signatures and JWT, with Ed25519 keys and session settings documented by the project. Anubis normally sits between nginx, Caddy, HAProxy, Traefik, or a Kubernetes ingress and the origin. It runs from images, packages, or system services. Trusted proxy headers, client address extraction, and the target URL must be exact.