Home

🇬🇧 English · 🇫🇷 Français

Hydra Wiki

Hydra is a self-hosted BitTorrent daemon built for scale and seeding: a Go control plane driving a purpose-built Rust engine ("Typhon"). It holds 100k+ torrents in a single instance, with a live SSE web UI, a native REST API, and a qBittorrent-compatible shim so your existing *arr / autobrr / cross-seed setup just works.

This wiki covers how to run it and the edge cases that aren't obvious from the README. If you just want to get started, see Installation and First Run.

Guides

• Installation and First Run — Docker Compose, first boot, login, adding your first torrent.
• Architecture — front/agent split, the two engines, Typhon, persistence.
• Networking Modes — direct, SOCKS5 egress, PROXY-v2 relay, gluetun with hot port rebind.
• Gluetun (VPN) — the full recipe for running behind a VPN: rotating port, LAN access, topology.
• Deployment Topologies — monolith, agent, front-only; sharding; which to pick.
• Categories and Routing — placement, strategy, and save-path per engine.
• Adding Torrents and Existing Data — download vs seed, skip_checking, and recheck of on-disk data.
• qBittorrent Shim and Automation — autobrr, Sonarr/Radarr, cross-seed.
• Configuration Reference — default.toml sections and the Config tab.
• Troubleshooting — the gotchas people actually hit.

Concepts in one minute

• Two engine roles. A race session (aggressive, low-latency, for hot downloads) and a hoard session (upload-optimized, for long-term seeding), each tuned independently. You can run any number of extra engines.
• Everything is a default.toml. Most keys are also editable live from the Config tab.
• The qBit shim is the integration surface. Point autobrr / *arr / cross-seed at /api/v2/* and they treat Hydra like qBittorrent.

The engine is hoard-first: some operations (recheck/verify, per-torrent category moves) are hoard-only by design. The race engine is a lean, short-lived download path and deliberately omits them.