rDownloader finds out by itself when a new version is out and shows it in the sidebar. What happens next depends on how you installed it: the portable archive and the Windows installer install the update themselves on one click, or by themselves once you switch that on — with a backup before it, and the previous version back automatically if the new one does not start — while a package manager or a container keeps that job, and rDownloader shows you its command.

Plugins update separately, from their repositories.

The Updates tab of Settings → System holds the check:

Setting	What it does	Default
Check automatically	Fetches a public, signed file from the project's GitHub releases and sends nothing about your installation	On
Channel	Stable gets releases only; Beta also gets pre-releases (vX.Y.Z-beta.N) and then the release that follows them	Stable
Check every	Hours between two automatic checks, 1 to 168	24

Check now checks at once. The card also says which version is installed and how it is installed (Installed as: Portable archive, Windows installer, Debian package, …), when it last checked and when it checks next, and You have the newest version. when there is nothing newer. The first automatic check runs a few minutes after the start, so it never holds the start up.

A newer version stands at the top of the card, highlighted: Version … is available, the release date, the first points of what is new, and the buttons for your installation — Install and restart and Download for the portable archive and the Windows installer, Download for a build you replace by hand, the command to copy for a package manager — and What's new, which opens the dialog with the full notes. Install and restart asks the same questions as in the dialog and then opens it to follow the restart.

What the check trusts. The list of releases is signed with rDownloader's update key, which is built into the program. A list that was altered, belongs to the other channel, is out of date or is older than one already seen is refused, and the card names why (see Troubleshooting below). rDownloader never offers a version older than the one running, and never a beta on the Stable channel. A downloaded update is kept only when its size and SHA-256 are exactly what the signed list announces.

Package managers carry no betas. Installed through Homebrew, Scoop or winget, rDownloader reads the Stable channel whatever you choose, and the card says so.

When a newer version is available, the sidebar shows Update available with the version. It opens the same dialog as What's new in the card: under What's new a few plain points of what the version brings you — what is new, what works better, what is fixed — then Full changes, the version's complete changelog as it was released, and the Release page with every download and its checksum, and what to do for your installation.

Installed as	The dialog offers
Portable archive, Windows installer	Download in the background and Install and restart — below — and a small Download manually link for doing it by hand
Debian package	sudo apt update && sudo apt install --only-upgrade rdownloader, and Download the package
RPM package	sudo dnf upgrade --refresh rdownloader, and Download the package
Homebrew	brew upgrade rdownloader
Scoop	scoop update rdownloader
winget	winget upgrade degoya.rDownloader
Container image	docker pull ghcr.io/degoya/rdownloader:latest, then recreate the container, for example with docker compose up -d; on the Beta channel the beta's own tag
Unknown, such as a build from source	Download

A command comes with a Copy button. rDownloader does not run it for you: installing a system package needs administrator rights, and a service that raised its own rights would be the opposite of running as your user. The apt and dnf repository carries releases only; a beta, or a package you installed from a downloaded file, is installed from its file (sudo apt install ./<file>.deb, sudo dnf install ./<file>.rpm), as the dialog says.

With the portable archive and the Windows installer, Download in the dialog fetches the new version in the background while rDownloader keeps running: into update/download in the data folder, checked against the signed list, with its progress in the dialog. When it says … is downloaded and verified, Install and restart uses that file and does not download it again. You can close the dialog meanwhile; a second Download joins the one that runs, and after a restart finds the file in a moment. Download manually is the browser's download, for keeping the file yourself.

With the portable archive and the Windows installer, Install and restart in the dialog does the whole update. It asks first — rDownloader stops for about a minute and starts again as … — and asks once more when downloads are running: they are saved and continue after the restart.

Then, step by step, each shown in the dialog and in the sidebar:

1. Downloading the new version, checked against the signed list — skipped when Download already fetched it; that file is checked once more instead.
2. Writing the backup before the update — below. When the new version needs a newer plugin contract, this step also fetches the plugin packages it needs from the plugin repository; the new version installs them at its first start, before it falls back to the plugins bundled with it.
3. Stopping rDownloader, the clean way that saves the queue. Open browser tabs and the capture agent do not hold it up, and it takes a minute at most; a service that still runs after two minutes is ended by the updater.
4. Installing: the portable archive's program files are replaced, and the previous ones are kept in a folder .previous beside them; the Windows installer is run silently.
5. Starting the new version and waiting up to 90 seconds for it to answer as that version.

The dialog follows the restart and reconnects by itself. It ends with Updated to … and Reload the page, which loads the new version's interface; when the update failed, with why and Try again. Should rDownloader not answer for six minutes, the dialog stops waiting and says what to do: end rDownloader if it still runs, and start it. The card under Settings → System → Updates shows the last update's outcome afterwards, as long as it fits the version that runs: once a later version is installed, Updated to … of the one before is gone.

Every other open page says so too. A browser tab that was open across the update — or one that stood open while a package manager or a new container image updated rDownloader — notices that the service now runs another version, when you open it and when it reconnects after the restart, and shows New version available — reload with a Reload button. It never reloads by itself, so nothing you are typing is lost. An ordinary reload is enough: the page is never taken from the browser's cache, only its unchanging files are.

Before it starts, the update needs the program folder to be writable and about twice the download's size free there; otherwise it says so and changes nothing.

The capture agent restarts itself. From 1.8.1 on, a running capture agent notices when its program file was replaced — by this update, the Windows installer, a package manager or a rollback — and within half a minute continues as the new version; its tray icon disappears for a moment and comes back. Nothing to do. A capture agent older than 1.8.1 does not: it keeps running its old program (on Windows from the .previous folder) until you quit it from the tray or sign out and in again. Whatever it still holds is moved into a .trash folder beside the program and removed by a later start; it no longer stops the next update.

The card shows the capture agent's version. From 1.9 on, Settings → System → Updates lists the version of every capture agent running right now (Capture agent: 1.9.0); one from before 1.9 reports none and is shown as before 1.9. When an agent is older than rDownloader, the card says Restart the capture agent with both versions: give it a minute, since an agent from 1.8.1 on restarts itself; if the hint stays, quit the agent from its tray icon or in Task Manager and start it again — on Linux systemctl --user restart rdownloader-capture does both. That happens with an agent older than 1.8.1, or one another user on the computer started. The card has no button for it: rDownloader cannot restart a program in someone's desktop session. Without a running agent there is no hint.

A capture agent installed without rDownloader updates itself (from 1.21). It has no service in its folder to replace it, so it checks the same signed releases on its own and offers Install update to … in its tray menu, or installs with rdownloader-capture update; see Desktop capture agent. The card then says that the agent offers itself the new version instead of asking you to restart it.

From the desktop agent's tray. While an update is offered, the capture agent's tray shows Install server update …. An agent paired with May install server updates starts the same install as Install and restart here; without that right the entry opens this page. See Installing the server's update.

Install updates automatically on the Updates tab lets rDownloader install an offered version by itself — the same download, backup and roll-back as Install and restart. It is off by default and only offered where the installation updates itself (the portable archive and the Windows installer); with a package manager or Docker it is greyed out and says why, since those update rDownloader themselves.

It waits until nothing has downloaded, post-processed or recorded for five minutes. A seeding torrent does not hold it back; it seeds on after the restart. With Install and restart only within a time window it installs only between From and Until, for example 03:00–06:00, in the bandwidth schedule's time zone; without a window, at any time. The same window holds for restarting automatically.

A version whose install failed or was taken back is not tried again by itself. The start is announced as the notification event update_available, and how the update ended, once per version, as update_installed or update_failed — see Operational events. The audit log records the install as the service's own.

Beside the service, the setting decides for the desktop capture agent as well; an agent installed on its own has its own switch — see Keeping it up to date.

If the new version ends right after its start, does not answer within 90 seconds or answers as another version, rDownloader goes back by itself: it stops the new version, puts the previous program back, puts the database back as it was before the update, and starts the previous version. The dialog then says … did not start properly, so … runs again. and why. Progress downloads made in the seconds between the backup and the stop is lost and simply downloaded again.

An update interrupted half way — a crash, a power cut — is finished or taken back at the next start, before the database is opened; you never end up with a mix of both versions.

The Windows installer's first update cannot be taken back by itself. Going back means reinstalling the previous version's installer, and rDownloader keeps that installer only from an update it installed itself. The first update after you installed with the installer by hand therefore has none, and the dialog says so before you confirm. Should that update fail, the new version stays installed and is started again (update.msi_rollback_unavailable); install the previous version from its release page if you need it. Every later update can be taken back.

Before the update changes anything, rDownloader writes into pre-update in its data folder (data/pre-update/ in the portable archive, %LOCALAPPDATA%\rDownloader\data\pre-update\ with the Windows installer):

• a copy of the database, rdownloader-<old>-to-<new>-<time>.sqlite3, checked for integrity and against the running version's schema before it is given that name;
• an encrypted full backup, when a backup passphrase is set up — sealed with your backup key, then opened and read to its end again. It is required when the new release changes the database; otherwise one that fails is noted in the log and the audit log, and the update goes on with the copy.

The three newest of each stay, apart from your scheduled backups, until the update is proven: the new version started and answered as itself, as Updated to … in the dialog says. From then on only what taking that update back would need stays — the newest copy and the newest encrypted backup — and once those are older than Keep the newest copy (14 days by default; 0 keeps them for good), they go too. An update that is not proven yet, was taken back or failed keeps every copy. The clean-up runs ten minutes after every start, daily after that, and on Clean up now — see Cleaning up the data folder.

If the copy — or, for a release that changes the database, the encrypted backup — cannot be written and checked, the update does not start (update.backup_failed) and the installed version keeps running unchanged.

Updates you install with a package manager or by hand do not write this backup; the copy that every first start of a new version makes before it migrates the database (Before an upgrade) covers those.

Only when the update ends with update.rollback_failed — the previous version could not be put back completely — is anything left to you:

1. Stop rDownloader (Stopping the service), or end the process.
2. Portable archive: in the program folder, move the files of the new version into a folder of their own, move every entry of .previous back to where it came from, and delete the folder .update-<version>. Windows installer: install the previous version's installer from its release page; if Windows refuses the older version, uninstall the new one first — your data stays.
3. In the data folder, delete rdownloader.sqlite3-wal and rdownloader.sqlite3-shm, and replace rdownloader.sqlite3 with the newest pre-update/rdownloader-<old>-to-<new>-….sqlite3.
4. Delete update/journal.json in the data folder and start the previous version.

Some changes take effect only at the next start of rDownloader, so that a running download never changes plugin half-way: a plugin installed or updated — by hand or by the automatic plugin update — a plugin version chosen, rolled back or put under test, a plugin switched on, off or removed, a signing key revoked or a package withdrawn. rDownloader then counts a restart as pending and says so:

• the sidebar shows Restart pending below the update notice (an icon in the narrow sidebar), which opens this tab;
• a notice at the top of the Updates card lists what waits — … installed, … updated: 1.2.0 → 1.3.0, … switched off — says how this installation comes back, and carries Restart now;
• the messages under Settings → Plugins that say a change runs after the next restart carry Restart now as well, and so does the setup wizard's note after it installed your services.

What a start already finds — a plugin that does not load at any start — does not count, so a restart never asks for the next one. The list lives in memory; the restart empties it.

Restart now asks first while downloads are running (Restart anyway): the stop saves them, and they continue after the restart. The page then shows rDownloader is restarting … and reloads by itself once the service answers again; after five minutes without an answer it stops waiting and says the service may need starting by hand. A restart replaces nothing — the same version comes back. While an update is being installed there is no separate restart; the update restarts the service itself.

The notice says which of these applies to your installation:

rDownloader runs	After Restart now
Under systemd — the units of the Linux packages, or a unit of your own with Restart=on-failure	It stops the clean way and ends with exit code 75; systemd starts it again
In a container	It stops the clean way and ends with exit code 75; the container's restart policy starts it again — restart: unless-stopped in the compose file. A container started without one (docker run without --restart) stays stopped: start it with docker start rdownloader. See Docker and NAS
Any other way — the portable archive, the Windows installer, started by hand or at login	It starts itself again: a small helper, started like the updater, stops it, starts the same program with the same arguments in the same folder, and waits until it answers as the same version
In the rare case it cannot repeat its own start	It stops; start it again yourself — the notice says so beforehand

Exit code 75 means only this restart. A stop you ask for — rdownloader stop, systemctl stop, docker stop — ends with 0, and rDownloader stays stopped.

Every restart is recorded in the audit log as a stop request and announced as the notification event service_restarting (Operational events).

Restart automatically when needed, beside Install updates automatically on the Updates tab, lets rDownloader carry out a pending restart by itself. It is off by default, and offered on every installation. It waits for the same quiet as the automatic install — nothing downloaded, post-processed or recorded for five minutes — and, with Install and restart only within a time window, for that window. With automatic plugin updates on, this switch is what brings an updated plugin into service without you.

The desktop capture agent's tray says restart pending on its server line and, paired with May install server updates, offers Restart server — see Restarting the server. An assistant reads the same notice with the MCP tool get_restart_status and restarts with restart_service; over REST it is GET and POST /api/v1/system/restart.

The card and the dialog show these codes with a sentence in your language. The check's own failures leave the installed version as it is; the next check tries again.

Code	What it means	What to do
update.not_configured	This build carries no update key — typically a build from source	Nothing; update by hand
update.not_published	No release has been published on this channel yet	Nothing, or switch to the other channel
update.fetch_failed	GitHub could not be reached	Check the network or proxy; the next check tries again
update.untrusted, update.bad_signature	The list is not signed with rDownloader's key, or was altered on the way	Nothing is installed. If it persists, something between you and GitHub changes the file
update.malformed, update.too_large, update.invalid, update.revoked	The list cannot be read, is too large, has invalid entries, or was withdrawn	Refused; the next check or the next release fixes it
update.wrong_channel, update.stale	The list belongs to the other channel, is out of date, or is older than one already seen	Refused on purpose; the next release's list fixes it
update.schema_version_unsupported	The list has a format this version does not know	Update once by hand; later versions read it
update.download_failed, update.size_mismatch, update.digest_mismatch	The download broke off, or the file is not the announced one; it was deleted	Try again; a repeated mismatch means the download is being altered
update.transfers_active	Downloads are running	Confirm with Install anyway — they are saved and continue after the restart
update.install_dir_not_writable, update.not_enough_space	The program folder cannot be written, or has too little free space	Fix the folder's permissions or free space, then install again
update.install_unsupported	This installation does not install updates itself	Use the command the dialog shows
update.backup_failed	The backup before the update could not be written and checked; the message names the step and the cause	Remove the cause — usually free space or the backup passphrase — and install again; nothing changed
update.updater_failed, update.updater_did_not_start, update.service_did_not_stop	The update could not take over from the running service	Nothing changed; try again, or update by hand
update.journal_invalid	The update's plan was not valid	Nothing changed; try again
update.unpack_failed, update.switch_failed	The download could not be unpacked, or the files could not be replaced	The previous version was put back; try again, or update by hand
update.unpack_failed with "remove ….previous" and access denied	Only when updating from 1.8.0 on Windows: a capture agent started before an earlier update still runs from .previous	End rdownloader-capture.exe in Task Manager, then Install and restart again; start the capture agent afterwards. From 1.8.1 on this no longer happens
update.installer_failed	The Windows installer failed	The previous version stays installed; its log is update\msiexec-install.log in the data folder
update.new_version_exited, update.health_timeout, update.not_confirmed, update.start_failed	The new version did not start properly	The previous version runs again with the database from before the update. Report it with a diagnostic bundle
update.msi_rollback_unavailable	The new version did not start, and the Windows installer's first update had no previous installer to go back to	The new version stays installed; install the previous one from its release page if you need it — above
update.interrupted	The update was interrupted before it changed anything	Nothing to do; the installed version was kept
update.rollback_failed	The previous version could not be put back completely	Follow Going back by hand
restart.transfers_active	Restart now while downloads are running	Confirm with Restart anyway — they are saved and continue after the restart
restart.update_running	An update is being installed	Nothing to do; the update restarts rDownloader itself
restart.already_restarting	A restart has already begun	Wait for the page to reload
restart.relaunch_failed	rDownloader could not start its helper to come back	rDownloader keeps running; restart it by hand (Stopping the service, then start it)

• Installation — every way to install, and where each keeps its data
• Backup and restore — the passphrase and the copy before an upgrade
• Troubleshooting
• Support matrix — which installation installs itself, and how that is tested