Motrix, long known as a clean GUI wrapper around aria2, is being rebuilt from the ground up. The new line is called Motrix Turbo v2, and it splits the download core away from the interface, then exposes that core through MDXP, an open protocol built on JSON-RPC 2.0. The same core drives the desktop application and a Docker-ready headless server with a web UI, which means browser extensions, a CLI client, and scripts can all talk to the engine without going through the GUI.
One thing to be clear about before anything else: v2 is a beta track, not a replacement. It currently sits at v2.0.0-beta.18, and several earlier betas were never published because they failed the project’s own release gates. Meanwhile the stable line has not moved since v1.8.19, released on 3 May 2023.
What you can install today
Track | Version | What it means for you |
|---|---|---|
Stable | v1.8.19 (May 2023) | Mature and widely packaged, but over three years without an update. It ships Electron 22, which is long out of support, so the browser engine inside the app carries unpatched Chromium vulnerabilities. Fine for casual local downloads; think twice before using it on machines that handle sensitive material. |
Beta | v2.0.0-beta.18 | Modern stack and a genuinely new architecture, but prerelease. Migration from v1 data has not been validated, the Windows installer is unsigned, and several package formats are missing. |
If you test v2, back up your existing Motrix data and downloads first, and run it in parallel rather than in place — a separate OS account, a separate machine, or a separate Docker data directory.
Why a desktop download manager still earns its place
Browsers handle ordinary HTTP downloads well enough, and a common myth is worth retiring here: closing a tab does not cancel a download in Chrome or Firefox. Quitting the browser does. What browsers genuinely do not do is speak FTP — Chrome and Firefox both removed FTP support in 2021 — seed torrents, or give you segmented transfers, per-task speed profiles, and reliable session recovery across reboots. Resume exists in browsers, but it depends on server support for range requests and offers no control when it fails.
That is the gap a dedicated manager fills. Motrix sits between a bare torrent client and a closed commercial tool: MIT-licensed, no ads, no subscription. The v2 beta pushes further by separating the engine from the shell, so you can run the desktop app on macOS, Windows, or Linux, or run the headless server on a NAS and drive it from a browser extension or a shell script.
It is not the only option, and an honest recommendation has to say so. Motrix Next is a separate project that presents itself as the next-generation successor to the original Motrix: a ground-up rewrite in Tauri 2, Vue 3, TypeScript, and Rust, using a maintained aria2-next engine, with an install footprint around 20 MB and stable releases shipping through 2026. Two projects now claim the Motrix lineage. Anyone choosing today should look at both. Beyond that, JDownloader, qBittorrent, and plain aria2 with AriaNg remain reasonable alternatives depending on whether your priority is HTTP acceleration, torrents, or headless automation.
How Motrix v2 separates the engine from the interface
The codebase is divided into strict layers, with CI enforcing the dependency boundaries between them. At the top sits the renderer, a React 19 interface that talks to the core over IPC. Below that is the app core, which manages tasks, settings, plugins, and the bridge. Next comes the engine adapter, and finally the aria2 download engine itself. Because the core does not depend on the UI, the same layer runs inside the Electron desktop app and inside the Node.js headless server.
The confirmed stack
Area | Technology | Role |
|---|---|---|
Desktop shell | Electron 43 | Application container |
UI layer | React 19 | Interface components |
Language | TypeScript 7, strict mode | Type safety across builds |
Validation | Zod | Settings, IPC payloads, and MDXP wire schemas |
Download engine | aria2 | HTTP, FTP, BitTorrent, and magnet transfers |
Persistence | SQLite | Session storage and crash recovery |
Plugin sandbox | QuickJS | Isolated extension runtime |
Server runtime | Node.js, containerised for Docker | Headless API and web UI |
This table lists only what the project’s own release notes and README state. Build tooling, CSS framework, linting, and test-runner choices exist in the repository but are not documented in the public release material, so they are left out here rather than asserted with version numbers that cannot be checked.
MDXP and the plugin sandbox
Communication happens over MDXP, the Motrix Download eXchange Protocol, built on JSON-RPC 2.0. It is what lets the Chrome and Firefox extensions hand a browser download off to the app. Plugins run inside a QuickJS sandbox as a single ES2020 module, denied Node.js APIs and denied direct file or network access. Anything a plugin needs from the outside goes through mediated, URL-scoped host permissions that the developer declares in motrix-plugin.json alongside activation events and required capabilities; Motrix surfaces those requests to the user for consent before granting them.
The SDK ships as four npm packages — @motrix/plugin-manifest-schema, @motrix/plugin-api, @motrix/plugin-cli, and the create-motrix-plugin scaffolder. Three official plugins are signed and bundled: Filename Template, Page Scraper, and URL Resolver. A public JSON feed at dl.motrix.app/registry powers both the in-app marketplace and the website listings.
Concurrency and speed: what the numbers actually mean
The figures you will see quoted around Motrix — up to 10 concurrent tasks and 64 threads per download — come from the v1 feature list, not from v2 benchmarks. They also need unpacking, because taken at face value they promise more than aria2 can deliver.
The 64 refers to aria2’s --split, which distributes segments across available sources. Connections to a single server are capped separately by --max-connection-per-server, and that value has been hardcoded to a maximum of 16 in aria2 for years. So for an ordinary HTTP download from one origin, 16 is your real ceiling regardless of what you type into the settings. Segmentation helps when the server throttles per connection; when the bottleneck is your own link or a per-IP cap at the origin, extra threads buy you nothing.
Torrent speed is a separate mechanism entirely. Automatic tracker-list updates improve throughput by finding more peers, which has nothing to do with thread counts. Third-party reports of dramatic speed jumps generally conflate the two. Treat any single-blog multiplier without a stated methodology as an anecdote, not a benchmark.
Beyond raw throughput, v2 offers multiple speed-limit profiles with separate upload and download caps, SQLite-backed session storage that restores transfers after a restart, per-file selection and magnet support for BitTorrent, automatic tracker list management with health checks, and UPnP/NAT-PMP port mapping.
From browser extension to Docker container
Motrix v2 extends beyond the desktop with a shared protocol library, a command-line client, browser extensions, and a plugin toolchain. This ecosystem is the direct consequence of the core/UI split rather than a bolt-on.
Desktop and browser integration
The desktop app registers handlers for motrix:// and magnet: links and associates .torrent files. The Chrome and Firefox extensions, built for Manifest V3, intercept a download in the browser and pass it to Motrix through native messaging. System notifications fire on completion, an in-app notification centre keeps a log, and the interface offers a customisable dashboard with transfer statistics, live activity, task tiles, and dark mode.
Headless server and remote CLI
For NAS and home-server use, Motrix publishes a multi-architecture Docker image to Docker Hub and GHCR. The beta uses the immutable tag docker.io/motrixapp/motrix-server:2.0.0-beta.18, and the included compose.yaml keeps server state separate from downloaded files. The runtime is non-root, supports a read-only root filesystem, and validates mount permissions before accepting work.
mkdir -p motrix-data downloads
sudo chown 1000:1000 motrix-data downloads
export MOTRIX_IMAGE='docker.io/motrixapp/motrix-server:2.0.0-beta.18'
export MOTRIX_PUBLIC_URL='http://nas.example.lan:8080'
docker compose pull server
docker compose up -d --waitThe Web service publishes on port 8080 and MDXP on port 16801. Set MOTRIX_PUBLIC_URL to the real approval URL that remote clients can actually reach — the Compose files deliberately refuse to substitute a misleading localhost value. If that URL is temporarily unavailable, an SSH operator can approve a pending client from inside the container:
docker compose exec server motrix-admin pairing pending
docker compose exec server motrix-admin pairing approve ABCD-EFGHRemote CLI and agent clients pair through a device-code flow. Browser extensions pair with the desktop app over native messaging; first-time extension pairing is not provided by the headless server. Plain HTTP is appropriate only on a trusted LAN — exposure to the internet or an untrusted network requires a TLS reverse proxy and firewall rules around the origin ports.
Automating downloads with the CLI
Per the beta documentation, @motrix/cli requires Node.js 22 or later. Install it globally from npm, or get it from the desktop app under Settings → Integration → Command-line tools.
npm install -g @motrix/cli # Requires Node.js 22 or later
motrix add https://example.com/file.iso --save-dir ~/Downloads
motrix list # List downloads
motrix watch --stats # Stream live progress as NDJSON
motrix pair --name my-nas # Pair with a remote or headless instanceBuilding a plugin
pnpm create motrix-plugin my-plugin
cd my-plugin && pnpm install
pnpm dev # Watch-build and launch Motrix with the plugin
pnpm exec motrix-plugin validate # Validate motrix-plugin.json
pnpm run pack # Create dist/<id>-<version>.moext
pnpm exec motrix-plugin lint # Check the packed bundleThe default scaffold is a beforeCreate URL resolver; pass post-action after the project name to start from an afterComplete notification plugin instead. Hooks include beforeCreate, beforeFinalize, afterComplete, and onError. Plugins can contribute callable commands and settings, and reach the runtime through the motrix:plugin-api virtual module.
Installing: which channel for which version
This is where most write-ups go wrong, because v1 and v2 are distributed completely differently.
Stable v1.8.19
The v1 line is broadly packaged, and the README documents every channel: on Windows, the Motrix-Setup-x.y.z.exe installer from GitHub Releases, plus choco install motrix and scoop install motrix; on macOS, brew install motrix; on Linux, AppImage, Snap, yay -S motrix from the AUR, and flatpak install flathub net.agalwood.Motrix. Two caveats worth knowing: Motrix may need sudo on first run under Linux to create its aria2 session file, and because the macOS bundle ID changed in v1.8.0, auto-update from v1.6.11 fails — the Motrix Install Assistant exists to work around exactly that.
Beta v2.0.0-beta.18
The beta is distributed only through the GitHub prerelease and the project’s own distribution, not through the community package managers above. On Windows it is x64 only — no arm64, no 32-bit — and the installer is unsigned, so expect a SmartScreen warning. macOS builds require version 12 or later and ship as .dmg or .zip for both Apple Silicon and Intel. On Linux the beta offers .deb for Debian and Ubuntu and .rpm for Fedora and openSUSE. Snap and AppImage are not published for this beta, and Flatpak is validated outside the release tag. If you install from Snapcraft, Flathub, or the AUR today, you are getting v1, not v2.
Glossary
MDXP — Motrix Download eXchange Protocol, an open JSON-RPC 2.0 protocol that lets browser extensions, CLI tools, and scripted clients communicate with the download core independently of the GUI.
Plugin sandbox — a QuickJS-based isolated runtime where extensions execute as a single ES2020 module, without Node.js APIs and without direct file or network access.
Device-code pairing — the authentication flow used by remote CLI clients to join a headless Motrix server instance.
What this means for your workflow
Core portability: the same download core powers the desktop GUI and the Docker headless server, so you can switch interfaces without migrating engines.
Extensible platform: MDXP and the plugin SDK turn Motrix from a standalone app into something scripts and extensions can drive.
Beta gaps are real: no Snap, no AppImage, no Windows arm64, unsigned Windows installer, and no validated migration path from v1.
The stable release is aging: v1.8.19 is from May 2023 and runs an end-of-life Electron. That is the single most important fact when deciding what to install.
Two successors exist: Motrix Turbo v2 from the original repository, and the separate Motrix Next rewrite. Compare both before committing.
Automation ready: the CLI and server mode make v2 viable for NAS and automation workflows where a GUI is unnecessary — once it leaves beta.
Additional resources
Motrix GitHub repository — source, releases, and the v2 beta notes
Motrix Next — the separate Tauri/Rust rewrite
aria2 manual — authoritative reference for
--splitand--max-connection-per-serverv1-only packaging: Snap, Flathub, AppImage — these track v1.8.19, not the v2 beta