RapidBay: a self-hosted torrent client that transcodes on demand for Chromecast, AppleTV and Kodi

The gap RapidBay fills between a torrent indexer and a television

A torrent indexer gives you a magnet link. A television gives you a screen. Everything between those two points is manual: pick a client, wait for the download, discover the container is unsupported, find subtitles, convert the audio, then cast. RapidBay is an attempt to collapse that chain into five steps the README lists explicitly: open the web app, search, select a video file, wait for download and conversion, then play or cast. The intended user is someone who already runs Jackett or Prowlarr and wants the last mile handled. It is not a media server in the Plex or Jellyfin sense. There is no library concept in the README, no watch state, no metadata scraper for posters or episode numbering. The unit of work is a single video file you chose from a search result, and the system's job is to make that file playable and then reclaim the disk. That framing matters, because it tells you what RapidBay is optimised for: transient playback, not collection building.

Search backends, magnet handling and the transcode pipeline

RapidBay does not scrape torrent sites itself. It delegates search to Jackett, Prowlarr, or both at once, and the README states that when both are configured, results are merged and deduplicated. That is a sensible division: indexer credentials and Cloudflare workarounds stay in the tool built for them, and RapidBay only has to speak one API. From a selected result the flow is download, then convert. The README describes automatic conversion of the video file and its subtitles so they play in all browsers, Chromecast and AppleTV, plus automatic conversion of audio tracks that browsers cannot decode into AAC. ffmpeg is the engine here, and mediainfo is installed alongside it, which suggests the app inspects the file before deciding what to do. There is also a magnet handler: visiting /registerHandler registers your running instance as the default handler for torrent links, and you can paste a magnet link straight into the search bar. Subtitle acquisition runs through OpenSubtitles.org. Disk space is cleaned up automatically, which is the mechanism that makes the whole design viable, because a service that downloads full video files and never deletes them would fill a VPS in days. The trade-off is implicit and worth stating: you are handing disk reclamation to the app, so anything it decides is stale may disappear.

Running it: Docker one-liners versus a manual install

The documented Docker path is a single command. For Jackett: docker run -p 5000:5000 -e JACKETT_HOST="http://your.jackett.host" -e JACKETT_API_KEY="YourAPIKey" hauxir/rapidbay. For Prowlarr, swap in PROWLARR_HOST and PROWLARR_API_KEY. The image is published as hauxir/rapidbay and listens on port 5000. Two docker-compose examples exist in the repository, one connecting RapidBay to Jackett and one to Prowlarr, which is the cleaner way to wire the two containers together. The manual path needs python3, python3-venv, ffmpeg, mediainfo and nginx on Ubuntu or Debian, or the brew equivalents on macOS. Python dependencies are installed either with uv sync, which the README calls the recommended route, or with a venv plus pip install . The app is then started from inside the app directory with uvicorn app:app --host 0.0.0.0 --port 5000 --workers 1 --timeout-keep-alive 900. That long keep-alive value is not incidental: a single worker holding a connection open for fifteen minutes is what streaming a transcoded file through this stack looks like. If you front it with nginx, which the dependency list implies you should, your proxy timeouts need to match or exceed that, or playback will die mid-stream. Beyond the search backend, the optional environment variables are OPENSUBTITLES_USERNAME and OPENSUBTITLES_PASSWORD, SUBTITLE_LANGUAGES (default English, formatted as a Python list literal such as "['en', 'de', 'es']"), PASSWORD to gate the interface, and RD_TOKEN or TB_TOKEN for Real Debrid and TorBox caching. If both debrid tokens are set, the README says Real Debrid is tried first with TorBox as fallback.

Subtitles are gated behind a paid OpenSubtitles account

This is the most concrete constraint in the README and it is easy to miss. Automatic subtitle download requires a VIP account at OpenSubtitles.org. Without one, the feature the README lists third, right after file selection, does not function. That turns a self-hosted project into one with a recurring third-party dependency and a credential you have to store in an environment variable. If you are evaluating RapidBay for an environment where external accounts are not permitted, or where you cannot justify the subscription, plan on supplying subtitles yourself or accepting playback without them. There is a partial mitigation: the README lists alass as an optional system dependency for subtitle synchronisation, which addresses timing drift between a subtitle file and a specific release rather than the acquisition problem. One is not a substitute for the other. The language configuration is also worth reading carefully, because SUBTITLE_LANGUAGES is passed as a string containing a Python list, not as a comma-separated value, and getting the quoting wrong in a docker run command or a compose file is an easy mistake to make.

Where RapidBay is the wrong tool

The absence of any library model is the first dividing line. If you want a catalogue that persists, with posters, watched flags and resumable playback across devices, RapidBay is not that, and its automatic disk cleanup is actively hostile to the idea. The second dividing line is legal and network exposure. RapidBay is a BitTorrent client. Running it on a VPS means the swarm sees your host's address unless you route the traffic elsewhere, and the project acknowledges this by linking a wiki page on tunnelling torrent traffic through NordVPN. That is not a footnote, it is a precondition for most people who would want to run this on rented infrastructure. The third is the debrid path. Real Debrid and TorBox caching is documented as a speed improvement, and if you use it, your downloads stop being peer-to-peer at all, which changes the risk profile but also means you now depend on a second paid service. The fourth is scale. The documented run command uses --workers 1. Nothing in the material indicates multi-user concurrency, per-user sessions or resource limits, so a household of simultaneous streamers is untested territory as far as the documentation goes. Finally, there have been no retrieved releases, so the project's versioning and upgrade story is not visible from the material available.

Alternatives and the difference in approach

The most direct comparison is peerflix-style command line streaming, which the repository's own topic list references. That approach hands a magnet link to a local player and streams it directly, with no server, no web interface, no transcoding and no casting. RapidBay's difference is that it inserts a server in the middle so that devices which cannot run a torrent client, such as a Chromecast or an AppleTV, can still play the result. The cost of that insertion is a host that must run ffmpeg, store temporary files and be reachable by every playback device. A second comparison is a full media server paired with a download client, where the download completes into a library directory and the server handles transcoding at playback time. That approach keeps the file, which RapidBay deliberately does not. If your goal is a collection, the media server route is the one that matches the goal, and RapidBay's cleanup behaviour will fight you. The Kodi path sits between the two: the README links a wiki page for using Kodi as a frontend, so RapidBay can act as a source for a device that already has a player and a library of its own.

Licence, maintenance and what to check before you deploy

RapidBay is MIT licensed. That is permissive: you can run it, modify it and redistribute it, and the repository includes the licence text. It says nothing about the content you stream through it, and it does not shield you from the consequences of running a BitTorrent client on a network you do not control. The MIT grant covers the software, not the use. On maintenance, the material gives you the current branch (master), the primary language (Python) and a last push date, and nothing else. No releases were retrieved, so there is no changelog to read and no version to pin. Practically, that means you should treat a Docker image tag as the unit of upgrade and read the commit history before pulling, rather than expecting release notes to tell you what changed. The dependency surface is also worth weighing: ffmpeg, mediainfo, optionally alass, plus Jackett or Prowlarr, plus an OpenSubtitles VIP account, plus optionally Real Debrid or TorBox. Each is a separate thing to keep current. Before deploying, the concrete checks are that your indexer answers API queries, that ffmpeg and mediainfo resolve on PATH in whatever container or host you choose, that your reverse proxy timeout is at least as long as the 900-second keep-alive, and that the volume RapidBay manages is one you can afford to lose.

Editorial conclusion

Adopt RapidBay if you already operate Jackett or Prowlarr, have ffmpeg and mediainfo on the host, and want torrent playback on a browser, Chromecast, AppleTV or Kodi without managing a media library. Do not adopt it if you need permanent files, if you will not pay for an OpenSubtitles VIP account, or if running BitTorrent from your own IP address is unacceptable. Before committing, verify that your Jackett or Prowlarr instance returns results through the API, that ffmpeg and mediainfo are on PATH, and that the disk RapidBay cleans up on its own is one you are willing to hand over.

Official sources

1. hauxir/rapidbay on GitHub
2. Issues
3. License: MIT
4. README