ja7ad/hydra

Fast, resilient, multi-source download manager and accelerator for Windows, macOS, and Linux.
https://hydra.javad.dev

• Overview
• Key Features
  • Engine
  • CLI
  • Desktop GUI
• Installation
  • Quick Install (Bash / PowerShell)
  • Homebrew (macOS / Linux)
  • Winget (Windows)
  • Linux Packages (Ubuntu PPA / Fedora COPR / Arch Linux AUR)
  • AppImage (portable, self-updating)
  • From Source
  • Browser Extension
• Uninstall
  • Quick Uninstall (prebuilt installs)
• Usage
  • Basic Download
  • Multi-Connection & Mirror Sources
  • Metalink
  • Cookies and Authenticated Downloads
  • CLI Compatibility (wget / curl Mode)
  • Interactive Queue Manager (TUI)
  • Remote Checksum Lookup & Verification
  • Portable GUI Profile
• Plugins
  • Plugin architecture
  • Sandbox and native trust
  • Plugin inputs and authoring
• Benchmark
  • A fair 100 ms path
  • Four public mirrors
  • Desktop download managers
• Embedding HYDRA — libhydra
  • Platform guides
• Contributing
• Code signing policy
• License

Hydra Download Manager (HDM) is an open-source, high-performance network file retriever and download accelerator designed for speed, resilience, and adaptability. It dynamically partitions downloads across multiple connections and independent mirror sources, continuously rebalancing work to maximize throughput without stalling on slow peers. It ships as both a wget/curl-compatible CLI and a cross-platform desktop download manager with browser integration.

macOS / Linux — installs the GUI bundle (GUI + CLI + browser extensions) by default:

curl -fsSL https://raw.githubusercontent.com/ja7ad/hydra/main/install.sh | bash

CLI only:

curl -fsSL https://raw.githubusercontent.com/ja7ad/hydra/main/install.sh | bash -s -- --cli

Windows (PowerShell) — installs the GUI bundle by default:

irm https://raw.githubusercontent.com/ja7ad/hydra/main/install.ps1 | iex

CLI only:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/ja7ad/hydra/main/install.ps1))) -Cli

The scripts detect your OS and architecture (amd64/arm64), fetch the matching archive from the latest GitHub release, and install it — on Linux and macOS to /usr/local (falling back to ~/.local; override with --prefix DIR), on Windows to %LOCALAPPDATA%\Programs\Hydra. The CLI lands under both hydra and the short hya; an existing hya on the same prefix is never overwritten. GUI installs also register the browser native-messaging host. Pin a release with --version vX.Y.Z / -Version vX.Y.Z, or download the archives yourself from the releases page.

Linux compatibility. The CLI archive is a static musl build with no shared library of any kind, so --cli works on any distribution — old LTS releases, minimal containers, Alpine — regardless of its glibc. The desktop artifacts (GUI archive, .deb, .rpm) link the system's GTK, X11 and ALSA and are built on Ubuntu 22.04, which puts their floor at glibc 2.35: Ubuntu 22.04, Debian 12, RHEL 9 and newer. The AppImage is built on Ubuntu 20.04 and goes further back, to glibc 2.31: Ubuntu 20.04, Debian 11 and newer.

A GUI install is a real desktop app, not a loose binary:

• Windows — start-menu and desktop shortcuts (-Desktop:$false skips the desktop shortcut) and an Apps & features entry, so Hydra is listed and uninstallable from Settings like any other app. A hydra-<version>-windows-portable-<amd64|arm64>.zip on the releases page is the alternative for a machine you cannot install on: unpack it anywhere, run HydraPortable.exe, and the app keeps its configuration inside the bundle instead of %APPDATA%\hydra.
• macOS — Hydra Download Manager.app is installed into /Applications (override with --app-dir DIR, e.g. ~/Applications), with its icon and name in Launchpad, Spotlight, the Dock and the app switcher. hydra, hya, hydra-gui and hydra-host in <prefix>/bin are symlinks into the app, so the CLI stays on PATH and one update refreshes both.
• Linux — the logo lands in the hicolor icon theme and a hydra.desktop entry in your applications directory (plus the prefix's, for a system-wide install), so the app shows up in the launcher, the dock and the switcher with its own icon.

Either way the GUI can update itself in place afterwards (Options → General → Check for updates), including an install that lives in a root-owned directory — it asks for authorisation before replacing those files.

Beta channel — --beta (-Beta on Windows) installs the newest -rc pre-release when it is ahead of the latest stable release; otherwise it installs the stable release:

curl -fsSL https://raw.githubusercontent.com/ja7ad/hydra/main/install.sh | bash -s -- --beta

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/ja7ad/hydra/main/install.ps1))) -Beta

The GUI's in-app updater follows the same rule: enable Options → General → Download Beta channel and update checks will also offer release candidates while one is ahead of stable.

macOS notes: since the app isn't notarized yet, Gatekeeper may block it — see the macOS Permissions Guide for granting the required permissions. If you installed via the .dmg and macOS refuses to open the app ("damaged" or "unidentified developer"), clear the quarantine attribute:

xattr -cr /Applications/Hydra\ Download\ Manager.app

CLI:

brew install ja7ad/tap/hydra

macOS Desktop App (GUI):

brew install --cask ja7ad/tap/hydra

Hydra Download Manager is in the Windows Package Manager repository as ja7ad.Hydra:

winget install ja7ad.Hydra

Update it later with winget upgrade ja7ad.Hydra, or remove it with winget uninstall ja7ad.Hydra.

Ubuntu / Debian-based (Launchpad PPA):

sudo add-apt-repository ppa:sonycore/hydra
sudo apt update
sudo apt install hydra-download-manager

The package is hydra-download-manager, not hydra — hydra in the Ubuntu archive is THC-Hydra, the login cracker, and it is what apt install hydra gives you.

PPA Repository: launchpad.net/~sonycore/+archive/ubuntu/hydra

Fedora / RHEL-based (Fedora COPR):

sudo dnf copr enable sonycore/hydra
sudo dnf install hydra-download-manager

COPR Repository: copr.fedorainfracloud.org/coprs/sonycore/hydra

Arch Linux (AUR):

Build from source:

paru -S hydra-download-manager
# or: yay -S hydra-download-manager

Precompiled binary:

paru -S hydra-download-manager-bin
# or: yay -S hydra-download-manager-bin

AUR Packages: hydra-download-manager | hydra-download-manager-bin

Install from Flathub:

flatpak install flathub io.github.ja7ad.hydra

Run Hydra:

flatpak run io.github.ja7ad.hydra

One file, no installation, no root. Download it from the latest release, make it executable, and run it:

chmod +x Hydra-*-x86_64.AppImage
./Hydra-*-x86_64.AppImage

aarch64 images are published alongside the x86_64 ones. Every release is built on Ubuntu 20.04 and verified to run on 20.04 through the current release, so one image covers the whole line and the distributions downstream of it.

The image carries the GUI, the hydra CLI, the hydra-host native-messaging bridge and the update finisher. On its first start it writes a menu entry, a copy of the browser extensions and the native-messaging manifests into ~/.local/share/hydra — all of them pointing at the image file, so moving or renaming it is repaired on the next launch. Nothing is written outside your home directory and nothing needs root.

Set HYDRA_APPIMAGE_NO_INTEGRATION=1 for a run that writes nothing outside your download directory. For a fully self-contained copy — settings included — create a directory named after the image with a .home suffix next to it (Hydra-0.3.14-x86_64.AppImage.home); the AppImage runtime then uses it as $HOME, which is what makes the image portable across machines on a USB stick.

Updates. This is the one Linux build Hydra can update itself: the deb and the rpm install into /usr, which only their package manager may rewrite, so the in-app updater offers you the new package instead of touching those files. An AppImage is a single file you own wherever you put it, so Update Now replaces that file and relaunches — including when it sits somewhere only root can write, where it asks for your password first. The image also advertises zsync update information, so AppImageUpdate and appimaged can update it too.

Because it does not bundle GTK, the graphics stack or ALSA — those come from your desktop, where they are already correct — a portal-capable desktop is still what the file dialogs need. Nothing else is required.

Ensure you have Rust (1.80+) installed:

git clone https://github.com/ja7ad/hydra.git
cd hydra
cargo build --release

The compiled binary will be located at target/release/hydra. To build the GUI and native-messaging host as well, run make build.

Hydra integrates directly with web browsers to automatically capture downloads, provide right-click context menu options, and intercept media streams. The extension popup can also hand each captured download the proxy the browser itself is using, for that download only.

Install the extension directly from the official store for your browser:

• Chrome Web Store (for Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera, Arc, and Chromium-based browsers):
  Chrome Web Store: Hydra Download Manager Integration
• Firefox Add-ons (AMO) (for Mozilla Firefox):
  Firefox Add-ons: HDM Integration
• Safari: Ships inside the macOS desktop application bundle (enable under Safari → Settings → Extensions).

Tip: In the desktop GUI, you can also view status and open extension store listings directly from Options → Extensions or the Extensions toolbar button.

Extension source code and resources are maintained under the extensions/ directory:

• extensions/chrome/ — Chromium MV3 extension source code (shared core).
• extensions/firefox/ — Firefox MV3 event-page add-on source.
• extensions/safari/ — Safari Web Extension resources.

Every installer also ships pre-built extension packages with the app in both packed (.zip / .xpi) and unpacked shapes:

• Chrome, Edge, Opera, Brave, Vivaldi, Arc, Chromium — open chrome://extensions (edge://extensions, opera://extensions, …), turn on Developer mode, choose Load unpacked, and pick the extensions/chrome/ (or bundled chrome/) directory. The manifest key pins the id to jpnonmbbkjdpeebdhkjoliklfhkdcomj across all Chromium browsers, matching the native-messaging host allow-list. The packed .zip is the Web Store upload format, and the signed .crx is for enterprise policy deployment (ExtensionSettings / ExtensionInstallForcelist against an update manifest you host).
• Firefox — open about:debugging#/runtime/this-firefox → Load Temporary Add-on… and pick extensions/firefox/manifest.json or the packed .xpi. Developer Edition, Nightly, and ESR can install it permanently after setting xpinstall.signatures.required to false in about:config.

To build and assemble extensions from a repository checkout:

make extensions                                   # -> target/extensions
make extensions ARGS="--crx-key path/to/key.pem"  # also sign a .crx

A .crx is packed whenever a signing key is available (--crx-key, $HYDRA_CRX_KEY, or target/hydra-chrome-crx.pem); --crx generates one if there is none. Sign with the key behind the pinned manifest key — any other key changes the extension id, and the script says so. ARGS=--sign additionally fetches an addons.mozilla.org-signed .xpi (needs web-ext and AMO API keys).

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/ja7ad/hydra/main/uninstall.sh | bash

To also delete config, state, and logs:

curl -fsSL https://raw.githubusercontent.com/ja7ad/hydra/main/uninstall.sh | bash -s -- --purge

Windows (PowerShell):

irm https://raw.githubusercontent.com/ja7ad/hydra/main/uninstall.ps1 | iex

To also delete config and state:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/ja7ad/hydra/main/uninstall.ps1))) -Purge

Winget:

winget uninstall ja7ad.Hydra

Homebrew:

# Uninstall CLI
brew uninstall hydra

# Uninstall macOS Desktop App (and zap settings)
brew uninstall --cask --zap hydra

The scripts remove binaries, extensions, manifests, desktop shortcuts, and startup entries. On macOS, they also remove the bundled app and package receipts. Config and state are kept by default (~/.config/hydra on Linux/macOS, %APPDATA%\hydra on Windows); use --purge / -Purge to delete them.

# Retrieve a file with automatic concurrency discovery
hydra https://example.com/archive.tar.gz

# Specify output destination
hydra https://example.com/archive.tar.gz -O output.tar.gz

hya works everywhere hydra does. Every install channel — the install scripts, Homebrew, the .deb/.rpm/AUR packages, the macOS .pkg and the Windows installer — puts the CLI on your PATH under both names. It is three letters to type, and it is also the name to reach for on a machine that already has THC-Hydra, the login auditor, which is hydra too. Shell completions are installed for both; hydra install-completions --bin-name hya adds them by hand.

# Explicit connection count (e.g., 8 connections)
hydra -x 8 https://example.com/largefile.iso

# Fetch across multiple mirror origins serving identical files
hydra --mirrors https://mirror1.example.org/file.iso https://mirror2.example.org/file.iso

A Metalink document supplies the three things a bare URL cannot: every mirror that holds the object, its exact size, and what it must hash to. HYDRA reads both dialects — Metalink 3.0 (.metalink, what mirrormanager and most distribution redirectors emit) and Metalink 4 / RFC 5854 (.meta4) — and needs no flag to do it:

# A document on disk, whatever it is called: the content is read.
hydra ./Fedora-Workstation.metalink

# A redirector that serves one. Detected from its Content-Type on the probe
# that was going to happen anyway.
hydra "https://mirrors.fedoraproject.org/metalink?repo=fedora-40&arch=x86_64"

# Or name it outright, when a URL reveals nothing about itself.
hydra --metalink https://example.org/big.iso.meta4

What that buys, over the same object fetched from one URL:

• Mirrors that can actually be assembled together. Splicing ranges across hosts is normally gated on every source agreeing about a strong validator — and independent mirror operators cannot share an ETag, so that gate keeps exactly one source out of a nineteen-mirror list. A document states the size and a content digest from outside the mirrors, so agreement is established against the document instead. Stronger, and satisfiable.
• A reserve bench. Politeness authorises a handful of connections; the rest of the list is held back. When a mirror dies or goes silent mid-transfer, its connections are re-pointed at a reserve in place — the socket count stays what politeness allowed, and no range is stranded.
• Localised repair. Where the document publishes <pieces>, each chunk is verified as the file lands and a bad one costs a single chunk refetched from a different mirror, not a whole re-download.

Read one without fetching anything, including what HYDRA would do with it:

hydra metalink ./Fedora-Workstation.metalink
hydra metalink --json https://example.org/big.iso.meta4

Narrow the choice:

# Prefer mirrors near you; the rest stay as reserves.
hydra --metalink-location de,nl,fr ./mirrors.meta4

# One entry from a document that describes several.
hydra --metalink-file netinst.iso ./mirrors.meta4

# Only entries for one platform, and only one protocol.
hydra --metalink-os linux --metalink-preferred-protocol https \
      --metalink-enable-unique-protocol ./mirrors.meta4

HTTP(S) mirrors are used first and ftp:// mirrors wait behind them as fallbacks, whatever the publisher's ranking says — ranges can be spliced and chunks repaired over HTTP, while FTP streams from a single connection (--metalink-preferred-protocol ftp restores the old order). Mirrors on schemes this build cannot fetch (rsync:// and friends) are reported and skipped rather than attempted; <metaurl> indirections such as BitTorrent are recorded and not followed; and a <file name> that tries to escape the output directory is refused outright. A <signature> is reported and not verified — verify it yourself before trusting the digests it covers.

Servers that implement Metalink over HTTP (RFC 6249) need no document at all: Link: <...>; rel=duplicate headers on an ordinary download become reserves, discovered on the probe that already happened.

The desktop app reads the same documents: paste a .meta4/.metalink path or URL into Add URL and it shows what the list offers — files, sizes, how many mirrors are usable, whether per-chunk verification is available — before adding one download per entry. libhydra exposes it too, through hydra_metalink_parse/_open/_fetch and hydra_job_create_from_metalink.

A file behind a login — a university mirror, a private GitLab artifact, a forum attachment, a paywalled dataset — needs the session your browser already has.

# A cookie string, the way curl spells it
hydra --cookie "session=abc; csrf=def" https://example.org/file.iso

# A Netscape cookies.txt, read before the first request and written back after
hydra --cookie-jar ./jar.txt https://example.org/file.iso

# wget's one-direction spellings
hydra --load-cookies ./cookies.txt https://example.org/file.iso
hydra --save-cookies ./cookies.txt --keep-session-cookies https://example.org/file.iso

# Or take them straight out of the browser that has the session
hydra --cookies-from-browser firefox https://example.org/file.iso
hydra --cookies-from-browser "chrome:Profile 2" https://example.org/file.iso

--cookies-from-browser reads the browser's own store — Firefox, LibreWolf and Zen from cookies.sqlite; Chrome, Chromium, Edge, Brave, Vivaldi and Opera from their encrypted Cookies database, decrypted through the platform keychain the way the browser does it; Safari from Cookies.binarycookies. A running browser does not have to be closed: the store is copied and read from the copy.

On macOS, a browser profile lives behind the system privacy control, so the first run reports that it cannot read the store and names the path. Grant Full Disk Access to whatever is running hydra — your terminal, or Hydra itself for the desktop app — in System Settings ▸ Privacy & Security, and try again.

Three things it will not do:

• Read more than it needs. Only the host being downloaded from is kept; the rest of the profile is discarded before the first request, and nothing is written to disk unless --cookie-jar or --save-cookies asked for it.
• Do it quietly. The run names the exact file it read and the host it read it for. A download manager that opens a browser keychain without saying so is indistinguishable from malware.
• Let a cookie cross an origin. The jar selects by the host of the request about to be sent, so a redirect from one site to another carries the second site's cookies and nothing else. Domain= may only widen a cookie to a domain the setting host is under, never to a public suffix. Values are never logged at any -v level, and a jar file is written 0600.

Following a redirect chain that hands out a session works with no flag at all: a Set-Cookie on a 302 is held for the rest of that chain, which is what a login-gated CDN expects. The jar dies with the chain — nothing is read from or written to disk unless one of the flags above asked.

In the desktop app, Add URL has a Cookies field, Options ▸ Connection ▸ Use cookies from picks a browser and profile for downloads added by hand, and Properties shows where a download's cookies came from. Captures from the Hydra browser extension already carry the page's own cookies and are unaffected.

HYDRA can seamlessly emulate wget or curl flags:

# wget dialect
hydra --compat=wget -c -O myfile.zip https://example.com/file.zip

# curl dialect
hydra --compat=curl -C - -o myfile.zip https://example.com/file.zip

The dialect is also taken from the name the binary is invoked as, so existing scripts can run unchanged. hydra compat-link installs those entry points:

# Show where the wget/curl links would go, and whether they would be reached
hydra compat-link --dry-run

# Create them next to the hydra binary
hydra compat-link

# Keep the real curl/wget names free
hydra compat-link --name hydra-wget --name hydra-curl

A link only takes effect from a directory that is on $PATH before the one holding the real curl/wget — otherwise the shell keeps resolving the name to the original tool. compat-link checks that and tells you which binary wins, so a link that cannot be reached does not look like a silent failure. Existing files are never replaced without --force.

# Launch interactive terminal UI
hydra interactive

# Add multiple downloads into the queue
hydra interactive https://example.com/file1.iso https://example.com/file2.zip

# Check remote advertised checksums without downloading the object
hydra checksum https://example.com/release.tar.gz

# Download with target hash verification
hydra --checksum sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 https://example.com/file.tar.gz

The desktop app keeps config.toml, its download list (state.redb), logs/ and locales/ in ~/.config/hydra (Linux/macOS) or %APPDATA%\hydra (Windows). --config points all of it somewhere else — a USB stick, a project folder, a second profile:

hydra-gui --config ./here

The path may be relative (it is resolved against the working directory at launch) and is created if missing. Such an instance is fully independent: it has its own download list and its own single-instance lock, so it runs alongside an ordinary Hydra. The login item ("launch on startup") is per user and cannot carry the flag, so it stays with the ordinary install. The browser extension reaches a running portable instance over its WebSocket port either way.

Browser capture while the portable copy is closed needs the native-messaging host, which a browser addresses by a per-user registration that carries no arguments. Options > Extensions > Let this copy handle browser capture registers the hydra-host sitting next to the portable hydra-gui and drops a hydra-profile file beside it naming the profile directory; the host reads that file and launches hydra-gui --minimized --config <dir>. It is off by default because the registration is per user: switching it on takes browser capture away from any ordinary Hydra install on the same account, and switching it off hands it back. HYDRA_CONFIG overrides the pointer file for scripted setups.

Hydra plugins add download sources and protocol engines through a shared API used by both the CLI and desktop app. Community authors build and install a .hyaplugin package; plugins using the existing API do not need changes to Hydra's crates. The package contains a manifest, a Wasm module, and any declared native libraries.

flowchart TD
    Hydra["HYDRA GUI / CLI"] --> Runtime["Plugin manager and Wasm runtime"]
    Runtime --> Resolver["Source resolvers: YouTube, media URLs"]
    Runtime --> Protocol["Protocol providers: Torrent"]
    Runtime -.-> Storage["Future storage providers: S3, WebDAV"]
    Resolver --> Plans["Validated download plans"]
    Protocol --> Plans
    Storage -.-> Plans
    Plans --> Coordinator["Hydra transfer coordination"]
    Coordinator --> Engine["HTTP / FTP engine and HLS / DASH transfers"]
    Coordinator --> Native["Trusted native backend: libtorrent"]
    Engine --> Scheduler["Adaptive concurrency, range stealing, stall detection"]
    Native --> Pieces["Peer sessions, piece selection and verification"]
    Scheduler --> Result["Files, resume state, progress and logs"]
    Pieces --> Result

Resolvers return URLs, tracks, headers and output descriptions. Hydra downloads those sources through its existing transport and media engines. Native transfer plugins return an engine identifier, file list and opaque engine metadata; Hydra coordinates their destination, selection, cancellation, rate limits and progress. The torrent plugin imports libtorrent as a library inside Hydra's process, where libtorrent handles peer discovery, torrent pieces and verification. Hydra's byte range scheduler applies to its own HTTP/FTP transfers.

Storage providers are an extension direction: an author could resolve authorized object URLs or implement a native transfer backend. S3, WebDAV, SFTP and IPFS in this architectural idea are possible future providers. The current API provides resolver plans and native transfers; it has no separate storage-provider hook.

Wasm plugins are sandboxed; native modules are trusted in-process components.

Wasm code runs with memory and execution limits. Network requests, cookies, plugin data, approved external tools and selected-file reads go through Hydra's host API and permission checks. Choosing a local file authorizes that input; it does not give the Wasm module unrestricted access to the filesystem.

A native module is an OS/architecture-specific .dll, .so or .dylib, declared in [[native_modules]] and authorized by permissions.native. Hydra checks the installed library's hash before loading it. Native code runs with Hydra's OS permissions, outside the Wasm sandbox, and can affect or crash the host process. A package containing native code therefore requires trust in that component. Package signatures authenticate the publisher and package contents; they do not sandbox native code or certify that it is safe.

URL claims choose candidate resolvers; the resolver still validates the input. Plugins also declare generic file actions, so the app can add a plugin-provided button below OK and Cancel in Add URL:

claims = ["magnet:*", "*://*/*.torrent", "*://*/*.torrent?*"]

[[input_actions]]
label = "Browse Torrent File"
extensions = ["torrent"]

The file extension declaration routes local inputs to the plugin in both frontends:

hydra ~/Downloads/example.torrent
hydra 'magnet:?xt=urn:btih:YOUR_INFO_HASH'

Another plugin can declare Browse X File with its own extensions using the same API. Native plans can declare the headings and live rows of the progress detail table in both the CLI and GUI. Hydra keeps the standard progress display, dialog styling and controls. Leveled plugin logs are available through Help → Logs; HYDRA_LOG=debug enables debugging details.

Create, build, validate and install a plugin with the authoring CLI:

hydra-plugin init my-plugin --language rust
hydra-plugin build my-plugin --output my-plugin.hyaplugin
hydra-plugin validate my-plugin.hyaplugin
hydra plugin install my-plugin.hyaplugin

Native libraries must be built for each target platform and included before packaging. Official desktop releases include YouTube and the signed torrent package matching the OS and CPU architecture. On first launch Hydra installs these plugins automatically. Application updates carry newer plugin versions; startup sync preserves plugin settings, saved data and disabled or removed plugins. Wasm plugins remain sandboxed; the bundled torrent library is a trusted in-process component signed by Hydra. On Linux, native plugins require a dynamically linked Hydra host: use the CLI included in the desktop bundle, a distro package, or a GNU-target source build. The standalone static musl CLI supports Wasm plugins but cannot load native libraries. See the Rust guest SDK, native ABI, and torrent plugin for working examples.

Measured on a Hetzner VPS (Ubuntu 24.04, 2 vCPU), one client process at a time with a cooldown between runs, every download verified against a reference SHA-256. hydra rows marked default are a bare hydra <url> with no flags. Everything here is reproducible with the scripts in scripts/benchmark/.

The origin is nginx serving 1 GB from RAM inside a network namespace on the same host, with 50 ms of tc netem delay each way: a 100 ms round trip, unlimited bandwidth, and no other traffic. Four plain curl ranges finish within 10 ms of each other, so the path is fair and the only variable is the client. Mean of three runs.

At every matched concurrency HYDRA is ahead of aria2c, issues exactly one request per connection with no repairs, and does it at a third of the memory and two thirds of the CPU. A bare hydra <url> matches aria2c -x 4 on speed while curl, wget and aria2c at their own defaults sit at a third of it. wget is the one client that uses less memory, 4.8 MiB against 6.9.

A bare hydra <url> against aria2c -x 4 and curl, two runs each on the same VPS. The Hetzner origin caps concurrency per client and refuses the surplus with 429; the other three reward it.

The second runs agree with the first to within a few percent on every row except mmatechnical, where the CDN warmed between them (hydra 392 MB/s, aria2c 420 MB/s on the second run).

Measured on a desktop PC with windows os (Windows 11, 16 GB RAM, and 8-core CPU) for download. 100MB.bin file from https://ash-speed.hetzner.com/100MB.bin with the same network.

hydra is the application. libhydra is the engine, and it is a product in its own right: a stable C ABI over hya-core and hya-net, with its own version, its own release archives, its own compatibility promise, and a permissive MIT-or-Apache licence rather than the CLI's GPL. A desktop application, an Android app, an iOS app, or a program in Go, Swift, Kotlin, Dart, C# or Python can run the same download engine without taking the CLI or the GUI with it.

make ffi          # libhydra.a, libhydra.so/.dylib, and include/hydra.h
make ffi-compat   # the ABI 1 stability gate
make ffi-test     # the ABI suite, a C conformance program, and every
                  # published header against the current library

#include "hydra.h"

hydra_engine_config_t cfg;
HYDRA_ENGINE_CONFIG_INIT(&cfg);
cfg.state_path = "hydra-state.json";     /* jobs survive a process restart */

hydra_engine_t *engine = hydra_engine_create(&cfg);

const char *urls[] = { "https://example.com/big.iso" };
hydra_job_config_t job;
HYDRA_JOB_CONFIG_INIT(&job);
job.urls = urls; job.url_count = 1; job.output_path = "big.iso";

hydra_job_id_t id;
hydra_job_create(engine, &job, &id);
hydra_job_start(engine, id);

Job identity is a durable uint64_t rather than a pointer, so it survives an app restart, a UI rebuild or a killed Android service; the event queue is the asynchronous interface, so it becomes a Go channel, a Kotlin Flow, a Swift AsyncStream or a Dart Stream; and file bytes never cross the boundary, so resident memory stays independent of object size.

The ABI is frozen and mechanically enforced. Within ABI 1 no field moves, no enumerator is renumbered and no symbol disappears; CI checks the whole layout against a committed manifest and compiles every header this project has ever published against the library built from the current branch. docs/ffi/ABI.md is the specification — design principles, the stability policy, and what the guarantees actually cover.

Every release publishes a prebuilt archive — static library, shared library, header, pkg-config metadata and these guides — for Linux (glibc and musl), macOS, Windows, Android and iOS. Any other target builds from source with scripts/build-ffi.sh --target <triple>, the same script CI runs.

See also docs/ffi/ABI.md for the specification, include/hydra.h for the published declarations, and examples/ffi-c/download.c for a complete C client with mirrors, pause and resume.

Contributions are welcome! Please read the Contributing Guide for the project layout, build instructions, pre-submit checks (fmt, clippy, tests), commit conventions, and how licensing applies to each crate. In short:

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-targets --all-features

Bug reports and feature requests go to the issue tracker; security vulnerabilities should be reported privately via GitHub security advisories.

Free code signing provided by SignPath.io, certificate by SignPath Foundation.

Windows executables, DLLs, PowerShell scripts and installers in official Hydra releases are signed from the ja7ad/hydra repository's release workflow. Only binaries built from this repository's source are signed.

Team roles

• Authors: committers and contributors
• Reviewers: @ja7ad
• Approvers: @ja7ad

Privacy policy

This program will not transfer any information to other networked systems unless specifically requested by the user or the person installing or operating it. The only automatic request is the update check against GitHub releases, which you can turn off under Options → General → Check for updates on startup. See the full privacy policy.

• The hydra CLI binary is licensed under the GNU General Public License v3.0 or later (GPL-3.0-or-later).
• The hydra-core, hya-net and hya-ffi libraries are dual-licensed under MIT or Apache-2.0 (LICENSE-MIT / LICENSE-APACHE).

For more details, see LICENSING.md and THIRD-PARTY-NOTICES.md.