Deploy Anubis | (Just Updated) Bot Blocker Proxy for AI Scrapers, Signing Key Pre-Set

Deploy and Host Anubis on Railway

Built for an LLM agent to deploy and use. The deploy form has no field to fill: ED25519_PRIVATE_KEY_HEX, the key Anubis signs its challenge cookies with, is generated for you, and the TARGET variable already points at a demo origin service so the whole path works the moment the deploy finishes. Anubis, the open-source proof-of-work bot filter from Techaro, sits in front of a website and makes browser-like clients solve a small hash puzzle before they reach it, which prices out AI scrapers and crawlers. The contract below lists every address, variable name and one script that shows a plain API client passing straight through while a browser-like client gets the challenge.

Anubis here is the official ghcr.io/techarohq/anubis image, version 1.28.2, pinned by digest, wrapped in a thin image that sets BIND to Railway's port, so it needs no start command and no entrypoint.

About Hosting Anubis

Anubis is a reverse proxy. Every request to the public domain reaches Anubis first; it applies its bot policy and forwards allowed requests to the address in TARGET. Clients with a browser User-Agent (anything containing Mozilla) are served a proof-of-work page and receive a signed cookie once they solve it. Other clients, such as curl and API libraries, are proxied straight through under the default policy, so an API behind Anubis keeps working for programs.

This template ships two services. anubis is the filter on the public domain. origin is a small demo web server (traefik/whoami, pinned by digest) that echoes the request it receives, including the X-Anubis-Action and X-Real-Ip headers Anubis adds, so you can see the filter working. To protect your own site, edit TARGET on the anubis service to the private address of your service, for example http://my-app.railway.internal:3000, redeploy, then delete the origin service.

ED25519_PRIVATE_KEY_HEX is generated once per deploy of the template and stays the same across redeploys, so cookies Anubis has issued remain valid after a restart. Anubis keeps no other state, so this template has no volume. PUBLIC_URL is set to the service's own public domain, which lets challenge redirects return to the right host.

To use your own bot policy, point POLICY_FNAME at a policy file you add to the image, as described in the Anubis documentation. The default policy ships inside the image.

Agent contract

• Public URL: https://$RAILWAY_PUBLIC_DOMAIN (the anubis service's generated domain)
• Private URL: http://anubis.railway.internal:8080
• Credentials: none to present. The variable ED25519_PRIVATE_KEY_HEX is the server's cookie-signing key, not a client credential; TARGET is the upstream address Anubis proxies to
• Auth: no header or login. Anubis decides per request from the User-Agent and its policy: a non-browser client is allowed and proxied, a browser-like client (User-Agent containing Mozilla) receives the challenge page
• Health: there is no health endpoint on the public port, and the deploy has no healthcheck. Readiness is GET / returning 200 from the proxied origin (the body begins Hostname:); Anubis metrics are served on port 9090 on the private network only
• Policy: the response header X-Anubis-Action seen by the upstream is ALLOW for requests that passed

# needs: RAILWAY_PUBLIC_DOMAIN of the anubis service
BASE="https://$RAILWAY_PUBLIC_DOMAIN"
# write-auth: none - Anubis is a filtering proxy with no credential; it forwards a non-browser POST to TARGET untouched, and the upstream decides whether to accept it
curl -s -o /dev/null -w "api client read: %{http_code}\n" "$BASE/"
curl -s -X POST -d 'x=1' "$BASE/" | grep -E '^(POST|X-Anubis-Action)'
curl -s -A 'Mozilla/5.0 (X11; Linux x86_64) Chrome/120' "$BASE/" | grep -o "not a bot!" | head -1

A fresh deploy prints api client read: 200, then POST / HTTP/1.1 and X-Anubis-Action: ALLOW (the origin echoing the request Anubis forwarded), then the browser-like request prints not a bot!, taken from the title of the challenge page ("Making sure you are not a bot"). If origin is replaced by your own service, the first line is that service's own status code.

Why Deploy Anubis on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Anubis on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

• Agent-ready - generated signing key, a contract block and one working script that shows both the pass-through and the challenge.
• Works out of the box - a demo origin is wired in, so you see the filter act before you point it at your own site.
• Stateless - no database or volume; restart or scale it without migrating anything.
• Private-network reachable - other Railway services can use anubis.railway.internal:8080 as their protected front door.
• Pinned - the Anubis image is fixed by digest, so a deploy does not change under you.

Common Use Cases

• Block AI scrapers and crawlers - make bulk scraping of a public site cost real CPU for every client that looks like a browser.
• Protect a self-hosted app from bot traffic - put Anubis in front of a wiki, Git forge or forum that is being hammered by crawlers.
• Cut origin load - challenge abusive clients before a request reaches an expensive upstream.
• Front an API that must stay open to programs - non-browser clients pass through while browser-shaped scrapers are challenged.

Dependencies for Anubis Hosting

• A service for Anubis to protect. The template includes a demo origin; replace it by editing TARGET.

Deployment Dependencies

• Anubis repository
• Anubis documentation
• Container image
• Wrapper image source

Implementation Details

Anubis listens on Railway's PORT (8080) and serves metrics on 9090 inside the container. No data directory.