Plugins are managed under Settings → Plugins, in four tabs:

• Installed groups installed plugins by the types actually present, with a count each, and shows per plugin which version runs and which one the next start runs.
• Catalogue takes a .rdplug package file and holds Services and plugins: every service the release ships and every plugin the repositories offer — installed, available or with an update waiting. The tab carries the number of waiting updates.
• Repositories lists the plugin repositories.
• Trust holds the packages this machine refuses and the confirmed publishers.

The tab is part of the address — /settings/plugins?tab=trust opens Trust directly.

Bundled and from the repository. Seventy-two ship in the release, next to the executable under plugins/. Only the services you chose are installed — in the setup assistant, or with one click on Install in the Catalogue — and serve updates the installed ones automatically at startup. An update never installs a plugin you did not choose; see Bundled plugins.

The repository comes first, the bundle is the fallback. Installing a service takes each of its plugins from the plugin repository when the repository offers the bundle's version or a newer one of the same plugin, signed with the same key, asking for no more permissions, and its host answers; otherwise the plugin comes from the bundle. Without a loaded index rDownloader fetches one first; a repository host that did not answer is skipped for five minutes. Without a network everything comes from the bundle beside the program. The Catalogue names each plugin's origin — Bundled, Repository or Uploaded: for an installed service where the installed version came from, otherwise where an install would take it from now.

A build that shipped without bundled plugins says so at startup. In Docker the log line is no bundled plugin packages found.

Further plugins and updates come from the plugin repositories — the official one is built in.

Before an application update. When an update of rDownloader needs a newer plugin contract, preparing the update fetches the matching plugin packages from the repository. The new version installs them at its first start, before it falls back to the bundle; nothing prepared is left behind after that start.

Manually. Install a .rdplug package through the web interface — at the top of the Catalogue, pick the file or drop it onto the upload field — or from the command line:

rdownloader plugin install myhoster.rdplug --root data/plugins

Every install from the web interface — an upload or a package from a repository, signed with a trusted key or not — first opens Review before installing: the package's name and version, the versions already installed here, the publisher (author and signing key), every permission it asks for — capabilities, Web addresses, Direct connections to — its release notes (none when they only say it is a maintenance release) and its package digest. For an update, New compared with v… comes first: the permissions the newest installed version does not have yet, each as a red badge, or a line saying it asks for nothing new. The publisher box shows the author and a line saying where the key stands; click it to see the key id and the fingerprint. For a key this installation has not seen yet it is open from the start, because that fingerprint is what you confirm. The package digest shows its first and last eight characters; click it for the whole of it. The key line says where the key stands:

A package that was withdrawn, or that this build cannot run, says so and cannot be installed.

When it runs. A hoster, multihoster or sign-in plugin installed for the first time runs at once, so an account you add right after can be tested straight away. Every other kind of plugin, and every update, becomes active after the next restart, so a running download never changes plugin half-way. The message after installing says which of the two it was; until the restart, testing an account whose plugin waits says installed; it runs after the next restart.

Restarting. A change that waits for the next start makes a restart pending: the message carries Restart now, the sidebar shows Restart pending, and Settings → System → Updates lists what waits. Running downloads are confirmed first and continue after the restart. With Restart automatically when needed switched on there, rDownloader restarts by itself once nothing has run for five minutes. See Restarting when needed.

Every .rdplug carries an Ed25519 signature. Verification happens when it is installed, and again at every startup.

Compiled code is cached, never trusted blindly. A compiled plugin is kept in plugin-cache/ in the data directory; a damaged, copied-in or unrecorded entry is deleted and compiled again, never run, and the package's signature is still checked first on every load.

Compiled into the application. Additional trusted release keys can be passed at service start, repeatable:

rdownloader serve --trusted-plugin-key KEY_ID=BASE64_PUBLIC_KEY

--no-default-plugin-key drops the compiled-in one.

When a package is signed with a key rDownloader does not know, the install preview — or the CLI — shows the fingerprint and asks you to approve it before the key is trusted persistently. The keys you approved are listed under Settings → Plugins → Trust → Confirmed publishers.

rdownloader plugin keys list
rdownloader plugin keys trust --from-package myhoster.rdplug
rdownloader plugin keys revoke <KEY_ID>

Every trusted key has a role — application release, plugin, tool manifest, repository — and an optional expiry, so a key can be rotated with an overlap window. A key trusted for one role signs nothing under another: a tool-manifest key cannot vouch for a plugin package.

An individual package can be withdrawn by its digest without revoking the key that signed it, and with it every other package of the same author. Withdrawing and lifting — a key or a single package — are recorded in the audit log.

A repository publishes one signed index of the packages it offers and of what it withdraws. A repository only delivers packages: each one still has to be signed by a plugin key you trust, exactly as an uploaded one does, and is installed only when it matches its index entry — size, digest, id, version, type, contract, signing key, author and permissions — and is signed at all, development mode or not. A package that differs is refused with The downloaded package does not match its index entry.

The repositories are listed under Plugin repositories in Settings → Plugins → Repositories:

• Official — the index attached to the newest rDownloader release, signed with the key compiled into the application. It is built in: it can be switched off (Use Official), never removed.
• A third-party repository is added under Add a repository with its Index address (https://) and its Repository public key (Base64), as its publisher publishes it. rDownloader fetches the index, checks that the key signs it and shows Approve the repository key with the key's fingerprint and the number of packages offered. Approve only if that fingerprint matches the one the publisher published. A changed key means removing the repository and adding it again.

The repositories are checked shortly after the service starts, then every 24 hours (Check every (hours), 1 to 168), and on Check now. Each repository shows when it was last checked successfully, until when its index is valid, and the reason when the last check failed. An index that is tampered with, signed by another key, older than one already accepted, or expired is refused whole. Offline, only a stored index that still verifies is used.

Switching a repository off stops its checks, updates and offers; Remove repository removes a third-party one. Either way, plugins installed from it stay installed.

Services and plugins on the Catalogue tab lists every bundled service and every plugin the repositories offer, filtered by All, Installed, Available and Updates, each with its count. Each entry shows whether it is installed, its origin, and Update available when a newer version waits: newer than every installed version and signed with the key the installed version is signed with. A newer version under another key comes from a different publisher and shows only as an offer. A bundled service installs on Install; a plugin only a repository offers opens the install preview through Review, so you see its publisher, permissions and release notes before anything is written.

Review update opens the install preview. An update that asks for a capability, a web address or a stream host the installed version does not have is marked New permissions and waits for your review in every case; hovering the mark names exactly what is new. An update set to install by itself is marked Automatic.

Each plugin's Versions panel has Install updates automatically. Switched on, the next repository check installs an update on its own — only under a plugin key that is already trusted, and never one marked New permissions. Either way, the update becomes active at the next restart.

To do this for every plugin at once, switch on Install updates of all plugins automatically at the top of Services and plugins. It covers every installed plugin and every plugin you install later. While it is on, each plugin's own switch shows on and cannot be changed; switch the one for all plugins off and every plugin goes back to the choice you made for it. The same rules hold: an update marked New permissions waits for your review, a plugin you rolled back or are testing keeps the version it runs, and an update becomes active only after a restart. To have that restart happen without you, switch on Restart automatically when needed under Settings → System → Updates (Restarting automatically).

Installing never removes the version it replaces: a download already under way keeps the version it started with. Each plugin card has a Versions row:

• Running — the version that runs now; From the next start — the one the next start runs, with Restart to apply when the two differ.
• Activate another installed version (Another installed version), or Roll back to the one that ran before.
• Test puts a version Under test beside the running one. Only downloads started with this version on purpose run it, until you activate it; Discard ends the test.
• Release notes — what the repositories say about each version, as plain text, newest first. For the official plugins these are one to three sentences per version on what you notice. A version that changes nothing you notice carries the newest notes that did, introduced with In :. Notes that only say a version is a maintenance release are left out, and notes several versions repeat word for word stand once, at the newest of them. Longer notes, from older indexes, are folded after three lines; More shows them whole.
• Superseded versions (N) — the installed versions that no longer load, collapsed; each can be withdrawn or removed from there, and Remove all removes all of them at once.

Remove superseded versions (N) beside the heading of the installed list removes the superseded versions of every plugin in one go; it shows only while there are any. Both ask once, with the number, and a message then says how many went and which stayed, each with its reason: a version a download that has not finished still uses, the version the next start runs — right after an update, the new one — and a version under test stay. The version that runs never goes.

The actions on the whole plugin sit at the bottom of its card, at the same place in every card: Delete on the left, Withdraw and Disable (or Enable) on the right.

Activating and testing refuse a version that would not load. Every choice takes effect at the next start. New work runs only the active version; the others serve only the downloads that started on them.

After an update, the version it replaced is the one Roll back returns to. A plugin you hold on another version on purpose — rolled back, an older version activated, or a newer one under test — keeps running it; the update waits installed beside it.

Trying a version on one download. Once a version under test is loaded (after a restart), a download whose hoster plugin has it offers Test with {name} v{version} in its row menu. It starts that download on the tested version. A running download keeps the version it started with; pause it first.

Every version choice is recorded in the audit log.

rdownloader serve --plugin-development-mode

Accepts unsigned packages. It is for local development only — never for a release, and never on an installation reachable from anywhere else.

The plugin manager has a list of its own for this, Packages this machine refuses under Settings → Plugins → Trust: it lists what is withheld, marks the affected version on its card, and lets you withdraw one build or lift it again.

• It takes effect at the next start. Nothing already running is torn down, exactly as with a revoked key.
• The author's signing key stays trusted, so every other plugin signed with it keeps loading.

Withdrawals from a repository. The official repository's index can withdraw single packages and whole signing keys; they appear in this list when the index is accepted. A package signed by a withdrawn key is refused outright, the trust prompt included. A third-party repository can withdraw only package versions that were installed here from it.

A download pinned to a withdrawn version is not moved to another version without a word. A download that would have started on its own is held, and every affected download says The plugin version … this download was pinned to has been withdrawn. Resuming it continues with the plugin's current version.

Every installed plugin can be:

• deleted, behind a confirmation;
• switched off without being removed — it stays installed and listed so it can be switched back on, but it is no longer loaded, compiled or executed, and its provider is no longer offered when creating an account.

A disabled plugin takes effect on the next start.

Incompatible plugins are skipped at startup without blocking the service, and are listed on the Installed tab of the plugin manager with the reason and a way to remove them. The two reasons: it was built for an older contract, or it asks for a permission this version does not know.

Each plugin carries a sanitised execution history: which version, which entry point, which failure class, with a quotable correlation id and no credentials. It is shown in the plugin manager (once there is something to show) and served by GET /api/v1/plugins/{id}/executions. A log line about a plugin carries its name beside its id.

The install preview shows the publisher, the signing key's standing and every permission the package asks for before you commit. Read the domain allowlist: a resolver that asks for a wildcard domain, or for credential expansion it does not need, is asking for more than its job requires.

What the sandbox does not allow in any case: no file system, no other processes, no network beyond the declared domains — a redirect to anywhere else included — no WASI.

• Plugin overview — what the types are and what each may do
• Bundled plugins
• Packaging, signing and distribution
• Security and privacy