rDownloader ships as a portable archive for Windows, Linux and macOS, as a Windows installer, as deb and rpm packages with an apt and dnf repository, through Homebrew, Scoop and winget, and as a container image for amd64 and arm64. None of them needs administrator rights to run it: the web interface is part of the server binary, and the service runs as your own user. Which systems, browsers and tool versions it needs, and how far each is tested: Support matrix.

Where each kind keeps your database and downloads is under Installed or portable: where the data lives.

Two programs come out of a release archive:

Every archive and installer also carries a VERSION.txt beside the programs, so you can tell which build you have without starting it: the version, the commit, the build time in UTC and the platform.

Beside the packages, every release carries rdownloader-plugin-index.json, the signed index of the release's plugins that the built-in official plugin repository reads by itself.

The container image contains the service only. On a NAS or a server, pair the browser extension or run the capture agent on your desktop against the remote service instead.

rdownloader-windows-x86_64.msi on the release page installs rDownloader for your user only: no administrator rights and no UAC prompt. The program goes to %LOCALAPPDATA%\Programs\rDownloader, and your Start menu gets a folder rDownloader with three entries:

The last page of the installer offers Start the rDownloader service at every login. Then open http://127.0.0.1:8710/ for the setup wizard. The capture agent's own start at login comes after pairing it, as with the archive (Running it at login).

The installer speaks four languages, one file each on the release page: rdownloader-windows-x86_64.msi in English, rdownloader-windows-x86_64-de.msi in German, -es.msi in Spanish and -fr.msi in French — the dialogs, the checkbox and the Start menu entries (Stop rDownloader is rDownloader beenden, Detener rDownloader, Arrêter rDownloader). An update from inside rDownloader installs the English one, so after it the Start menu entries are in English again.

Windows SmartScreen may warn about the download. The installer and the programs are not code-signed yet, so Windows can show Windows protected your PC for a file it has not seen often. Check the file against SHA256SUMS on the release page, then choose More info → Run anyway.

Unattended, from a terminal:

msiexec /i rdownloader-windows-x86_64.msi /qn             # install
msiexec /i rdownloader-windows-x86_64.msi /qn AUTOSTART=1 # and start the service at every login
msiexec /x rdownloader-windows-x86_64.msi /qn             # uninstall; your data stays

Three more switches set up the capture agent's desktop integration for the installing user: ASSOCIATION=1 the file association for .nzb, the link containers and .torrent, DROPSHORTCUT=1 the Add to rDownloader shortcut on the desktop, SENDTO=1 rDownloader under Send to. Uninstalling removes all three.

The exit codes are msiexec's own: 0 done, 1602 cancelled, 1603 failed, 1638 another version is installed, 3010 done but Windows wants a restart.

Upgrading means running the newer installer — or letting rDownloader do it, with Install and restart. The installer stops the running service and capture agent first, replaces the program and keeps the login start. It refuses an older version than the one installed; uninstall first to go back — your data stays.

Uninstalling (Settings → Apps or msiexec /x) stops both programs and removes the program, the Start menu folder and the login entries. It never touches your data in %LOCALAPPDATA%\rDownloader.

Every release carries a .deb and an .rpm for x86-64 and for 64-bit ARM (rdownloader-linux-x86_64.deb, rdownloader-linux-aarch64.rpm and so on). The easiest way to install them, and to get every later release, is the apt or dnf repository below; a downloaded file installs the same way:

sudo apt install ./rdownloader-linux-x86_64.deb    # Debian, Ubuntu
sudo dnf install ./rdownloader-linux-x86_64.rpm    # Fedora

Like the archives, the packages need glibc 2.39 or newer (Ubuntu 24.04, Debian 13, current Fedora); they recommend ffmpeg, yt-dlp and 7zip. The program goes to /usr/lib/rdownloader, the commands rdownloader and rdownloader-capture to /usr/bin, and two systemd user units come with it, hardened so that neither the service nor anything it starts — a post-processing script included — can gain privileges, sudo among them (see Security and privacy). The package starts nothing by itself — the service runs as your user, started by you:

systemctl --user daemon-reload
systemctl --user enable --now rdownloader      # now and at every login

Then open http://127.0.0.1:8710/ for the setup wizard — or choose rDownloader in your desktop's application menu, which starts the service if it is not running and opens the interface in your browser (the first start can take a minute while it prepares the plugins; reload the page then). Your data lives in ~/.local/share/rdownloader. To keep the service running while you are not logged in — on a server, say — let your user manager outlive your session with sudo loginctl enable-linger $USER.

The capture agent needs a graphical session and a pairing first:

rdownloader-capture configure --token-stdin    # the capture token from Settings → Clients & API → Desktop
systemctl --user enable --now rdownloader-capture

After an upgrade the running service keeps the old program until systemctl --user restart rdownloader. Removing the package (apt remove, apt purge, dnf remove) leaves ~/.local/share/rdownloader as it is.

A signed repository at https://degoya.github.io/rdownloader-packages carries the deb and rpm packages of every release, for x86-64 and arm64. Set it up once, and the system's own updates bring every new release.

Debian and Ubuntu:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://degoya.github.io/rdownloader-packages/rdownloader.asc | sudo tee /etc/apt/keyrings/rdownloader.asc > /dev/null
curl -fsSL https://degoya.github.io/rdownloader-packages/rdownloader.sources | sudo tee /etc/apt/sources.list.d/rdownloader.sources > /dev/null
sudo apt update
sudo apt install rdownloader

Fedora (dnf) and openSUSE (zypper):

sudo curl -fsSL -o /etc/yum.repos.d/rdownloader.repo https://degoya.github.io/rdownloader-packages/rdownloader.repo
sudo dnf install rdownloader
# openSUSE: sudo zypper addrepo https://degoya.github.io/rdownloader-packages/rdownloader.repo && sudo zypper install rdownloader

Then start the service as above. apt upgrade and dnf upgrade install each new release. The repository's indexes and the rpm packages are signed with the key 47562DABFCFC3F17C78567CE395FA7C2B11721D1; compare it with the fingerprint dnf shows on the first install, or with gpg --show-keys /etc/apt/keyrings/rdownloader.asc. The two newest versions of each package stay in the repository, so you can go back one: apt install rdownloader=<version> or dnf downgrade rdownloader. The repository carries releases only; a beta is installed from its file on the release page.

rDownloader keeps its database, its secret store and the installed plugins in a folder data/, and the default download folder downloads/ beside it. Where those two sit depends on how you installed it:

An installed build is marked as installed. The Windows installer and the deb and rpm packages put a small marker file beside the program, and a program that finds it moves into your user's data folder before it opens anything. That is why none of them ever keeps data in its program folder, and why an upgrade or an uninstall never removes it: the installer does not know that folder. A portable archive has no marker, so its programs work in the folder you start them from — the launchers start them in their own folder, which is why everything lands beside them. You can move, copy or delete that folder as a whole.

Two things follow from the marker:

• rdownloader serve, doctor, stop and auth find the data by themselves, and so do plugin keys and plugin install for their database and plugin folder; a file you name on the command line is still read from the folder your shell is in. --database and --root name another data folder.
• Moving from the portable archive to an installer: stop the portable copy (and run autostart remove for both programs if you registered them), move its data/ and downloads/ folders into the data folder in the table, install, start. Going the other way is the same move back. From Homebrew, Scoop or winget it is the same copy from their folder.

A storage root you set up yourself stays where you put it in every case; only the default download folder moves with the data.

A package manager installs and upgrades rDownloader with one command.

Homebrew (macOS on Apple Silicon and Intel, Linux on x86-64 and arm64):

brew install degoya/rdownloader/rdownloader
brew services start rdownloader        # now and at every login

Then open http://127.0.0.1:8710/ for the setup wizard. The service runs in $(brew --prefix)/var/rdownloader: the database, the secret store and the installed plugins in data/, the default download folder in downloads/, the log in $(brew --prefix)/var/log/rdownloader.log. brew upgrade rdownloader keeps all of it; restart with brew services restart rdownloader. Leave the login start to brew services — rdownloader autostart install would run the service in the installed version's folder and keep its database there, not in var/rdownloader. rdownloader-capture is installed beside it; to start it at every login as well, pair it once and use its own formula:

brew install degoya/rdownloader/rdownloader-capture
rdownloader-capture configure --token-stdin   # the capture token from Settings → Clients & API → Desktop
brew services start rdownloader-capture

On macOS it runs in your login session with its tray icon (capture agent). The external tools come from Homebrew as well, for example brew install ffmpeg yt-dlp. The macOS binaries are ad-hoc signed, not notarized; a Homebrew download carries no quarantine flag, so Gatekeeper lets them run. Linux still needs glibc 2.39 or newer (below).

After an upgrade on macOS the keychain may want your approval. The key of the secret store lives in your login keychain (item rDownloader, account master-key), and macOS lets only the build that created it read it without asking. A background service cannot show that question, so it stops at once — whether macOS declines to ask or rejects the new build outright — and its log ($(brew --prefix)/var/log/rdownloader.log) says keychain_interaction_refused, names the item and repeats the way out below. Stop the service with brew services stop rdownloader, start it once in a terminal with cd "$(brew --prefix)/var/rdownloader" && "$(brew --prefix)/opt/rdownloader/libexec/rdownloader" serve, choose Always Allow, stop it with Ctrl+C and run brew services start rdownloader again. Instead you can open Keychain Access, find the item rDownloader and allow the new program under Access Control. Nothing in the secret store is changed while it waits for you.

Scoop (Windows x86-64):

scoop bucket add rdownloader https://github.com/degoya/scoop-rdownloader
scoop install rdownloader
start-rdownloader

The launchers (start-rdownloader, stop-rdownloader, start-capture, stop-capture) and both executables are on PATH, and the Start menu has rDownloader and rDownloader Capture. The launchers run the service in the app folder, and Scoop keeps its data and downloads folders in its persist folder, so scoop update rdownloader keeps the database, the plugins and the downloads. Stop the service and the capture agent before updating. Typed into a shell, rdownloader serve uses the current folder instead, as it does from the archive.

To start both at every login, pair the capture agent once and register them:

rdownloader autostart install
'<TOKEN>' | rdownloader-capture configure --token-stdin   # the capture token from Settings → Clients & API → Desktop
rdownloader-capture autostart install

The login entries — and rdownloader-capture scheme install and association install — name Scoop's current folder, not the version folder, so they survive scoop update rdownloader and scoop cleanup without being installed again.

winget (Windows x86-64):

winget install degoya.rDownloader
start-rdownloader        # in a new terminal, which sees the changed PATH

winget installs the portable archive for your user into %LOCALAPPDATA%\Microsoft\WinGet\Packages\degoya.rDownloader_…\ and puts that folder on your PATH, so both programs and the four launchers (start-rdownloader, stop-rdownloader, start-capture, stop-capture) work from any terminal. The launchers run the service in that folder, so your data lives there too: data\, downloads\, logs\ and run\ beside rdownloader.exe. Typed into a shell, rdownloader serve uses the current folder instead, as it does from the archive.

winget upgrade degoya.rDownloader replaces only the program's own files and keeps the data; stop the service and the capture agent first, since Windows does not replace a running program. winget uninstall degoya.rDownloader leaves the folder with your data in place — unless you add --purge, or your winget settings purge portable packages on uninstall. Every stable release is submitted to the winget community repository and appears there once its review has passed.

Homebrew, Scoop and winget carry stable releases only.

1. Extract the release archive anywhere you have write access — no installer, no registry entries needed.
2. Run start-rdownloader.bat. It starts the service and the capture agent; pass server or capture to start only one of them.
3. Open http://127.0.0.1:8710/ and work through the setup wizard.
4. Run stop-rdownloader.bat, then start-rdownloader.bat again so the settings take effect.

Server on a NAS, capture agent on this PC. Double-click start-capture.bat: it starts only the capture agent, and stop-capture.bat stops it. Pair it once — the service's web interface shows the command under Settings → Clients & API → Desktop. Until then the start reports that it is not paired yet.

No Visual C++ redistributable is required.

Two messages during startup are not failures and need no action: the capture agent has not been paired yet, and something already listens on Click'n'Load port 9666 — usually a second capture agent from autostart, or JDownloader. Anything else is a real failure, and the batch launcher keeps its window open so the reason stays readable. Set RDOWNLOADER_NO_PAUSE=1 to suppress that pause for an unattended run.

Extract the archive and use the launchers next to the executables:

./start-rdownloader.sh                 # service + capture agent
./start-rdownloader.sh server          # service only
./stop-rdownloader.sh capture          # capture agent only
./start-capture.sh                     # capture agent only, server on a NAS or in Docker
./stop-capture.sh

Logs are appended below logs/, PID files are kept below run/.

There are two Linux archives: rdownloader-linux-x86_64.tar.gz for x86-64 and rdownloader-linux-aarch64.tar.gz for 64-bit ARM, a Raspberry Pi with a 64-bit OS included. Both are built on Ubuntu 24.04 and need glibc 2.39 or newer: Ubuntu 24.04 and later, Debian 13, current Fedora and Arch. On Debian 12 or Raspberry Pi OS bookworm (glibc 2.36) they do not start (GLIBC_2.39 not found) — use the container image there, which carries its own glibc. The minimums of the other platforms are on the support matrix.

The capture agent on Linux has no tray icon; its status comes from the systemd user unit that autostart install writes.

Extract the archive and use the .command launchers:

./start-rdownloader.command            # service + capture agent
./stop-rdownloader.command all
./start-capture.command                # capture agent only, server on a NAS or in Docker
./stop-capture.command

Separate builds exist for Intel (x86_64-apple-darwin) and Apple Silicon (aarch64-apple-darwin). The archive also contains rDownloader Capture.app, the helper that makes .nzb file association work; keep it next to rdownloader-capture.

docker compose -f docker/compose.yml up -d

The compose example publishes the service on the host loopback only, adopts the host user through PUID/PGID, and keeps /config and /downloads as persistent mounts. The image carries the external helpers the service shells out to — ffmpeg, yt-dlp, streamlink, gallery-dl, 7-Zip, par2 and Apprise — so media, streams, unpacking, PAR2 repair and Apprise notifications work without further setup.

/downloads is only the fallback destination. Every path you use as a storage root has to be mounted as a volume too. Anything written outside a mount lives in the container's writable layer and is lost when the container is recreated. rDownloader flags such a root in the routing view and in the readiness card.

The full deployment guide is Docker and NAS; a Synology NAS has a walkthrough of its own, Synology NAS.

The portable launchers are meant for portable operation and testing. For a normal per-user start at login, install autostart for each binary separately:

rdownloader autostart install
rdownloader-capture autostart install

Use both on a local desktop. When the service runs on a NAS, configure only the desktop agent against the NAS and install only its autostart:

printf %s '<TOKEN>' | rdownloader-capture configure --service https://nas.example --token-stdin
rdownloader-capture autostart install

Hand the token over with --token-stdin. --token <TOKEN> works too, but an argument is readable by every local user through ps or the task manager, and the shell keeps it in its history.

A service address that is neither loopback nor https is refused at pairing time, because the capture token travels with every request. --allow-insecure-service accepts one for a network you vouch for. The rule is checked when pairing, not when connecting: an existing plain-http pairing keeps working, and the agent writes a warning naming the address on every start until you pair again over https.

autostart remove on either binary disables future login starts without stopping the process that is currently running. Linux uses systemd user units, macOS uses LaunchAgents, and Windows uses a windowless per-user launcher.

The installers have their own way: the Windows installer's Start the rDownloader service at every login (or AUTOSTART=1) runs rdownloader autostart install for you, and the deb and rpm packages bring systemd user units that systemctl --user enable switches on (above). Homebrew leaves the login start to brew services.

rdownloader serve \
  --database data/rdownloader.sqlite3 \
  --downloads downloads \
  --listen 127.0.0.1:8710

Every flag has an environment variable:

--listen and RDOWNLOADER_LISTEN always win over the ui_port setting, so a bad port entered in the interface can never lock you out.

A clean stop lets rDownloader save the queue and every transfer's progress before it ends, so everything continues where it stood at the next start.

rdownloader stop                 # waits up to 60 seconds for the service to end
rdownloader stop --wait 120      # waits longer; --wait 0 returns once the service accepted

rdownloader stop stops the service on this machine that keeps its data in the folder it looks in: for an installed build your data folder, found by itself; otherwise data/ below the current folder — run it in the portable archive's folder — or the database you name with --database or RDOWNLOADER_DATABASE. It uses a key the running service writes into its data folder at every start, so nothing else is needed — no password, no token. Its exit codes, for a script:

The other ways to stop it:

• Windows: stop-rdownloader.bat (the Start menu's Stop rDownloader with the installer, stop-rdownloader with Scoop and winget) runs rdownloader stop first and ends the process only if the service does not answer or is still running afterwards. The service also stops on Ctrl+C, when its console window is closed and when Windows shuts down — but Windows ends the process a few seconds after the last two whatever it is doing, so the stop launcher is the way that waits for the queue to be saved.
• Linux and macOS: the launchers, systemctl --user stop rdownloader and brew services stop rdownloader send the service the usual termination signal, which stops it just as cleanly.
• Docker: docker stop, for the same reason.

rDownloader checks for new releases by itself and says so in the sidebar; the portable archive and the Windows installer then install the update themselves on one click, with a backup before it and the previous version back automatically if the new one does not start. With a package manager it shows you the command instead. Both are described on Updates.

By hand it is always the same: stop the service, replace the program with the new release — run the newer installer, or apt upgrade, dnf upgrade, brew upgrade, scoop update, winget upgrade (above) — and start it again. The database migrates itself on the first start, and a bundled plugin strictly newer than the installed one is installed automatically; the older version stays and can be removed from the plugin list once nothing is bound to it. Plugins update from their repositories.

When a release raises the plugin contract, plugins built against the previous contract no longer load. The bundled ones are replaced by the upgrade, and queued downloads re-resolve by themselves; a third-party plugin has to be rebuilt. The one download that has to be started again is one in progress on a transfer-backend plugin. See Plugin overview.

Back up data/ — it holds the database, the encrypted secret store and the installed plugins — before replacing anything. See Backup and restore.

The toolchain and the procedure for every platform are on Building from source.

• First run — the setup wizard
• Updates — the update notice and installing an update
• Docker and NAS
• Synology NAS
• External tools — yt-dlp, ffmpeg and friends
• Support matrix — what runs where, and how it is tested
• Desktop capture agent

Reference in the repository: README.md · docker/README.md