Hydra Launcher: an Electron and Rust game library manager that torrents its own installs

What Hydra Launcher actually solves, and for whom

The pitch in the README is a single tool for managing a gaming library. That framing matters, because Hydra is not a store. The feature list starts with adding games that you own to your library, which places the project in the launcher-and-tracker category rather than the storefront category. Around that core sit a profile that shows friends what you are playing, cloud saves through Hydra Cloud, achievements, and a catalogue with a suggestion algorithm.

The intended user is someone whose games are scattered across several sources and who wants one window for launching them, plus a lightweight social layer. The secondary user is a contributor: the repository ships .cursorrules, .codex/, .husky/, commitlint.config.js and an ESLint configuration, which is the furniture of a project that expects pull requests rather than one that expects to be consumed as a binary only.

One caveat sits at the front of the feature list. Adding games you own is a manual, user-driven operation in the description given. Nothing in the README claims automatic discovery of installed titles across stores, so anyone hoping for a scanner that finds everything on disk should treat that as unverified.

Electron shell, React renderer, Rust torrent engine

The README states the stack plainly: Node.js with Electron, React and TypeScript, plus Rust, with libtorrent providing the torrent engine. The repository layout backs this up with three separate TypeScript configurations (tsconfig.node.json, tsconfig.web.json, tsconfig.test.json) and a native/ directory alongside src/.

The split follows the usual Electron shape. The main process is Node and gets its own tsconfig; the renderer is the React application and gets another; the preload bridge comes from @electron-toolkit/preload. The typecheck script runs both projects in sequence, which is a small but real signal that the two halves are compiled under different assumptions and are not allowed to drift.

The unusual part is the torrent layer. Rather than shelling out to a torrent client or binding to a JavaScript implementation, Hydra wraps libtorrent in Rust and exposes it as a native addon. The README says the native build includes a Rust wrapper around pinned libtorrent, and that development and packaged torrenting no longer require Python. Pinning libtorrent is the kind of decision that trades upgrade friction for reproducibility, and the note about Python reads like the removal of an earlier build dependency.

There is also a big-picture entry point. The package scripts include dev:big-picture, which runs Vite against src/big-picture. That suggests a second surface beyond the main window, though the README does not describe what it does.

Installing Hydra Launcher from source

The README does not give install commands. It points to the documentation site at docs.hydralauncher.gg/getting-started for building from source and contributing, and the homepage at hydralauncher.gg is the other entry point. What the README does give is the requirement list and the package scripts, which is enough to describe the shape of a build.

The stated local development requirements are Node.js with Yarn, a Rust toolchain for hydra-native, and Git plus a C++ toolchain (Visual Studio C++ Build Tools on Windows, GCC or Clang on Linux, Xcode command-line tools on macOS). The README notes that the native build obtains CMake and CTest automatically through vcpkg.

Package management is enforced. The engines field in package.json declares npm as please-use-yarn and yarn as >= 1.19.1, so the first command is not optional:

yarn install

The postinstall hook is where the real work happens. According to package.json, postinstall runs three steps: npm run build:native, then electron-builder install-app-deps, then node ./scripts/postinstall.cjs. The README confirms that after installing dependencies, postinstall builds the Rust native addon automatically at hydra-native/hydra-native.node. If that file is not present after install, the torrent engine was not built.

To run the app in development against the source tree:

yarn dev

That maps to electron-vite dev. A production-style build is yarn build, which runs typecheck first and then electron-vite build. Platform packaging scripts exist for Windows, macOS and Linux (build:win, build:mac, build:linux), each of which builds the native addon before invoking electron-builder.

Configuration for a local instance comes from .env.example, which lists five keys with empty values: MAIN_VITE_API_URL, MAIN_VITE_AUTH_URL, RENDERER_VITE_REAL_DEBRID_REFERRAL_ID, RENDERER_VITE_TORBOX_REFERRAL_CODE and MAIN_VITE_LAUNCHER_SUBDOMAIN. The README does not document what each one must be set to, so a self-hosted or modified build has to work that out from the source.

On Windows, the README's badge row links a Chocolatey package named hydralauncher, which is the closest thing to an install command the repository advertises.

The build toolchain is the adoption cost

The most concrete limitation is stated in the requirements themselves. Building Hydra from source needs Node, Yarn, Rust, Git, a C++ toolchain, and vcpkg pulling CMake and CTest. That is a heavy prerequisite set for a desktop application, and it exists because the torrent engine is a compiled native addon rather than a JavaScript dependency.

The consequence is that the build is platform-sensitive in a way a pure Electron app is not. Windows needs Visual Studio C++ Build Tools, Linux needs GCC or Clang, macOS needs Xcode command-line tools. A contributor who only wants to change a React component still pays the full native build cost on first install, because postinstall runs build:native unconditionally before anything else.

A second limitation is documentation scope. The README documents features and build requirements, and it delegates everything else to docs.hydralauncher.gg. It does not describe how to remove Hydra cleanly, where library data is stored, how to export it, or how to roll back a version. For a tool whose value proposition is managing a library, the absence of a documented export path is worth weighing before you put years of playtime into it.

The feature list also leaves integration boundaries unclear. Hydra Cloud, achievements and the suggestion algorithm are named but not specified. Whether achievements come from the games themselves, from Hydra's own service, or from a third party is not stated in the README. Treat those as features to verify against the documentation site rather than as settled behaviour.

Hydra Launcher compared with Playnite and Lutris

The obvious comparison is Playnite on Windows or Lutris on Linux. Both are library aggregators, and both lean on store integrations and plugins to populate a library automatically. Hydra's README does not describe that kind of automatic import; it describes adding games that you own, which reads as a more manual model.

The sharper difference is the torrent engine. Playnite and Lutris are launchers and wrappers around other people's clients. Hydra ships its own torrent stack, a Rust wrapper around pinned libtorrent, compiled into the app as a native addon. That is a much larger surface to maintain, and it is also why the build requirements look like a systems project rather than a UI project.

The third difference is the social layer. Hydra Cloud, profiles and achievements are first-party features in the repository, not plugins. Playnite's equivalent functionality generally arrives through extensions. Which model suits you depends on whether you want a curated set of built-in features or a marketplace of smaller ones.

Note that this comparison is drawn from the README and repository files only. No head-to-head testing was performed, and no performance or compatibility claims are being made about any of the three.

Maintenance, releases and the MIT licence

The repository is not archived. The last push was on 2026-09-18, three days before the date used here, so the project is being worked on at a steady cadence. Releases follow a similar rhythm: v4.1.2 on 2026-08-21, v4.1.3 on 2026-09-04, and v4.1.4 on 2026-09-17. package.json carries version 4.1.4, matching the newest release tag.

That cadence shapes the upgrade cost. A three-week release interval on a desktop app with a native addon means the native build is a recurring cost, not a one-time setup, unless you stay on packaged releases. The build scripts recompile the addon on every build:win, build:mac, build:linux and build:unpack invocation, so packaged builds from source are never cheap.

Licensing is MIT, which is permissive and places few conditions on redistribution or modification. The practical implication for anyone planning to fork or bundle Hydra is that the libtorrent dependency is separate from the MIT grant on Hydra's own code, and the README does not state libtorrent's licence or version. If you intend to redistribute a build, that is the thing to check first. This is a description of the licence text, not legal advice.

The repository also carries a SECURITY.md, which is the place to look for how vulnerabilities should be reported. The README does not summarise its contents.

Editorial conclusion

Adopt Hydra Launcher if you want a single local library for games you own and you are comfortable running a build that compiles a Rust addon against libtorrent. Do not adopt it if you expect a packaged installer to be the whole story, or if you need documented data-export and rollback procedures, because the README does not describe either. Before committing, run yarn install and confirm hydra-native/hydra-native.node exists, then check whether the API and auth endpoints in .env.example are ones you are willing to point a desktop client at.

Frequently asked questions

Official sources

1. hydralauncher/hydra on GitHub
2. License: MIT
3. Project website
4. README
5. Releases