# Electorrent puts a remote torrent client behind one desktop window > Electorrent is a GPL-3.0 Electron application that connects to six torrent clients, uTorrent, qBittorrent, Transmission, rTorrent, Synology Download Station and Deluge, so magnet links and torrent files can be sent to a NAS, VPS or seedbox from the desktop. It has a built-in trust system for self-signed certificates, fuzzy search and automatic updates from the GitHub repository. **tympanix/Electorrent** — A remote control client for µTorrent, qBittorrent, rTorrent, Transmission, Synology & Deluge - Repository: https://github.com/tympanix/Electorrent - Stars: 1,196 · Forks: 98 - Language: TypeScript - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/tympanix-electorrent ## The problem is a web interface on the wrong machine Electorrent opens with the whole argument in two sentences. No more! Stop copy/pasting magnet links and uploading torrent files through a tedious webinterface. Electorrent is your new desktop remote torrenting application. Remote control your NAS, VPS, seedbox, you name it. The setting is a real one. Someone runs a torrent client on a machine they do not sit in front of, because that is where the storage is or because it is the only machine with the connectivity. The client has a web interface, and that web interface is a small page served over a link that is slow, or a phone browser, or a reverse proxy somebody set up in a hurry. Adding a torrent is copy a magnet link, switch tabs, paste, wait for the upload to complete, and find out whether it worked. So Electorrent is not a torrent client. It is a remote control for one, and the description in the package.json says exactly that, A thin client for your torrenting needs. That framing is what keeps the feature list short and the whole project small. The client support list is the core of it. - µTorrent - qBittorrent, v3.2.x and above - Transmission - rTorrent - Synology Download Station - Deluge Six clients, each with its own API, which is the real engineering problem in the project and the reason a thin client is not a trivial thing to build. The repository is an Electron application with an AngularJS front end, and the FAQ states the technologies directly. The application is built around Electron, AngularJS and Fomantic UI. The primary language is listed as TypeScript, and the repository layout has src/ for the source, a separate app/ directory for the Electron main process, build/ and assets/ and resources/ and util/ and scripts/, plus an electron-builder.yml and a webpack.config.js. ## Six input paths, and the magnet link is the reason it exists The feature list is a list of input paths, and the magnet handling is at the top of it. Connects to your favorite torrent client. Handles the magnet link protocol when browsing websites. Upload local torrent files by browsing your filesystem with Ctrl/Cmd+O. Drag-and-drop support for torrent files. Paste magnet links directly from the clipboard with Ctrl/Cmd+I. Quickly change between multiple server configurations. Native desktop notifications. Fuzzy searching of torrents. Built in certificate trust system, for self-signed certificates. Easy one click installer using the Squirrel framework. Automatic updates straight from the GitHub repository. The magnet link handling is the feature the whole project exists for. A magnet link is a URI, so it can be recognised in a web page, in the clipboard, or in a drag, and the point of the tool is that you never have to select it by hand or type it into a slow web form. The clipboard binding and the filesystem dialog are the two that make it a daily driver rather than a utility. A user with a seedbox adds a torrent by copying a magnet link and pressing one key. The same user with a local torrent file drags it onto the window. Both paths end in the same operation on the remote client. The multiple server configuration support is the other practical one. A person with a NAS, a VPS and a seedbox has three clients, and switching between them should not mean retyping a host and a password. The feature list calls it quickly change between multiple server configurations, and the quick change is the point. The built in certificate trust system deserves a note, because it solves a problem that only exists because the client is on another machine. A qBittorrent or Transmission instance behind a self-signed certificate, or behind a VPN, presents a certificate the desktop does not trust, and the alternative in a browser is a warning you click through every session. Trusting it once in the application removes that friction permanently, and the README lists it explicitly for self-signed certificates. ## The rTorrent caveat is the whole integration story The FAQ answers the question that most of the supported clients will raise, which is what happens when the connection does not work. The question is I can't connect to rTorrent, what is wrong? The answer is that when using rTorrent you have to configure your http server correctly, with a link to the rTorrent wiki guide for setting up the RPC, and an alternative that you may be able to use /plugins/httprpc/action.php as the path if you have the HTTPRPC plugin installed. That answer is instructive about the project as a whole. rTorrent does not have a modern API of its own, it has an XML-RPC interface, and that interface is served by the web server in front of it, so the client is not talking to rTorrent at all, it is talking to a path on a web server that forwards to rTorrent. The Electorrent connection to rTorrent is therefore contingent on a server configuration that is outside the application, and the project can only point at the documentation. The repository confirms the shape of that integration. There is a devDependency on @electorrent/xmlrpc and the runtime dependencies are small. q at ^1.5.1 is the promise library, winreg and electron-regedit are Windows registry packages, geoip-country is a country lookup library, and less at ^4.4.1 is the stylesheet language used with Fomantic UI. The Windows registry packages are the most platform-specific entries in that list, which fits the separate Windows build in the download list. ## Electron, but with the packaging and update machinery done properly The scripts in package.json show the build and the testing, and they are the most modern part of the project. The build is webpack with a production mode, and the packaging is electron-builder, with the dist script running electron-builder with publish never, the pack script running electron-builder --dir, and the postinstall running electron-builder install-app-deps. The test setup is worth a paragraph. The test command is wdio run ./wdio.conf.ts, so the tests are WebdriverIO end to end tests driving a real application, and there is a smoketest script that is more specific. ``` "smoketest": "npm test -- --client qbittorrent:latest --mochaOpts.grep \"torrent is stopped and resumed\" --headless" ``` So the test suite spins up a qBittorrent container, runs the tests headless, and greps for one named scenario, a torrent that is stopped and resumed. That is an integration test against a real torrent client rather than a mock, which is the only kind of test that proves the client integrations work. The linting combines eslint with a TypeScript build check, and there is a tsconfig.base.json and a tsconfig.json, and the module type is module, so the source is ES modules. The distribution is a set of platform builds, a Windows 64 bit build, a MacOS dmg and a Linux AppImage, and the one click installer uses the Squirrel framework, and the updates come straight from the GitHub repository. The release version is kept in sync with the app by a script, since the version script runs node ./scripts/sync-app-version.js and then stages app/package.json, which is the detail that keeps the application version and the package version from drifting. The download page note is important for anyone installing it. Please note: I do not own code signing certificates which may results in anti-virus warnings! ## Where Electorrent is the wrong choice The first wrong case is a user who wants to download something locally. There is no local downloading, no seeding and no file management, because the tool is a remote. A user who wants a single desktop torrent client should use a desktop torrent client, and every mainstream one of those has a native application already. The second wrong case is a client that is not in the list. The FAQ answer to your program sucks, it doesn't support my bittorrent client, is an invitation to open an issue saying which client you would like to see next. Six clients is a good number and it is not comprehensive, and a user on a client outside the list has to keep using the web interface. The third wrong case is a remote client behind a configuration the tool cannot help with. The rTorrent case is the explicit example, where the integration depends on a web server path and a plugin that the application cannot configure for you, and the same applies to any client behind a reverse proxy with a non-standard path, a self-signed certificate chain the trust store does not handle, or an unusual port. The fourth wrong case is a security conscious deployment. The application stores the credentials for your torrent clients, the Windows build reads them from the registry, and the builds are not code signed so the operating system will warn. A user who is already careful about what runs on their machine has a legitimate reason to prefer a browser interface over an unsigned Electron binary holding seedbox credentials. ## How it differs from the web interface it replaces The comparison worth making is with the web interface every one of these clients already ships, and the difference in approach is where the code runs and what it is optimised for. A client's web interface is a server-rendered page served by the client itself, so it works over any link and it needs no software on your machine. It is also designed for administration rather than for adding torrents, which is what makes it tedious for that one job. The pages are built for a browser on the same network, so on a slow link or a phone the form is unpleasant, and the file upload for a torrent file goes through the browser's file picker and the server's upload handling. Electorrent inverts that. The client library runs on your desktop, the connection is a direct API call to the remote client, and the interface is a native window with fuzzy search, clipboard and drag-and-drop input and desktop notifications. The thing the web interface does badly, which is getting a magnet link into the client quickly, is the entire product. The second difference is the input path. A web interface is a form, so every torrent is a sequence of clicks and a paste. Electorrent watches for the things you are already doing, a magnet link in a web page, a link on the clipboard, a torrent file dragged onto the window, and turns them into an operation on the remote client. That is not a small difference in convenience, it is the difference between a task you do a few times a week and one you avoid. The third difference is the credential handling. The web interface asks you to type the password every time or to store it in the browser. Electorrent stores the server configurations, so the connection is configured once. The fourth difference is what the web interface does better. A browser interface needs no installation and no native binary, it is one URL, and it is the only option that works when you are on a machine that is not yours. Electorrent gives that up for the convenience, and for a user who only occasionally adds a torrent the web interface is still the better answer. ## Conclusion Electorrent fits a user with a seedbox, a NAS or a VPS running one of the six supported torrent clients who wants to add torrents from the desktop without dealing with a web interface on a slow link or an awkward mobile page, and it fits a team that wants one consistent remote across different client software. It does not fit a user who wants a full torrent client, since it deliberately has no local downloading, and it does not fit a machine that cannot reach the client's API. Before adopting it, note that the Windows build is 64 bit only and the builds are not code signed, so the README warns about anti-virus warnings, and check the current release, v2.17.1 from 2026-09-18, with the last push on 2026-10-09. ## FAQ ### Which torrent clients can Electorrent connect to? Six: µTorrent, qBittorrent at version 3.2.x and above, Transmission, rTorrent, Synology Download Station and Deluge. The README invites an issue describing a client you would like supported next. ### How do I add a torrent to a remote client with Electorrent? Several ways: the magnet link protocol is handled when browsing websites, magnet links can be pasted from the clipboard with Ctrl/Cmd+I, local torrent files can be uploaded by browsing the filesystem with Ctrl/Cmd+O, and torrent files can be dragged and dropped onto the window. ### Why can I not connect to rTorrent with Electorrent? Because rTorrent's RPC is reached through the web server in front of it, so you have to configure that http server correctly using the rTorrent wiki guide. An alternative is to use /plugins/httprpc/action.php as the path if you have the HTTPRPC plugin installed. ### What platforms does Electorrent have builds for? Windows at 64 bit only, MacOS as a dmg and Linux as an AppImage, with a one click installer using the Squirrel framework and automatic updates straight from the GitHub repository. The author notes that there are no code signing certificates, so anti-virus warnings are expected. ### How is Electorrent built and tested? With webpack for the build and electron-builder for packaging, and the tests are WebdriverIO end to end tests driven by wdio.conf.ts. There is a smoketest script that runs against a qBittorrent container in headless mode, and the lint script runs eslint over the source and the test directory and then a TypeScript build check. ## Sources - [Issues](https://github.com/tympanix/Electorrent/issues) - [License: GPL-3.0](https://github.com/tympanix/Electorrent/blob/master/LICENSE) - [README](https://github.com/tympanix/Electorrent/blob/master/README.md) - [Releases](https://github.com/tympanix/Electorrent/releases) - [tympanix/Electorrent on GitHub](https://github.com/tympanix/Electorrent) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tympanix-electorrent