One queue spans direct files, torrents, streams, and eD2K
FluxDown combines download types that usually send you to separate applications. Its Rust engine handles HTTP and HTTPS, FTP, BitTorrent and magnet links, eD2K, HLS, and DASH. SQLite stores progress for resume after a crash or restart, while a Flutter interface presents queues, segment activity, and rate controls. Browser extensions for Chrome, Edge, and Firefox can hand links and detected media to the same local service.
Distribution is just as broad. Release v0.5.2 includes packages for Windows x64 and ARM64, Intel and Apple Silicon Macs, x64 Linux, 3 Android architectures plus a universal APK, and x64 or ARM64 servers. The release also supplies Docker, Synology, QNAP, and OpenWrt options, a standalone CLI, and SHA-256 checksum files.
The MCP endpoint puts 12 download actions behind one token
FluxDown can expose a Streamable HTTP MCP endpoint at http://127.0.0.1:17800/mcp. Its 12 tools add, list, inspect, pause, resume, and remove downloads, with more tools for queues and RSS subscriptions. The server shares a bearer token with the management API. Desktop users enable the endpoint in settings, while the headless server enables it by default and asks for a token during initialization.
That local default is sensible because download_remove can optionally delete the downloaded file. Keep the listener on loopback unless you have an authenticated network boundary, use a separate secret rather than a token copied into shell history, and scope the AI client to a machine whose files it is allowed to manage. MCP makes the queue convenient to automate. It also turns a download manager into a file-affecting agent tool, so confirmation and logs belong in the client workflow.
What happened when we ran it
Our sandbox installed commit 9d156b8 in 17 seconds with Bun. It added 48 packages and used 42 MB on disk. The checkout was much larger: 1,746 files, roughly 397,234 lines of source, and 75.6 MB. We ran inside a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The install step succeeded.
No build script or target was available to the detected Node project, so the lab skipped the build. There was also no test script or target, and tests were skipped. FluxDown does contain a tests directory, 7 CI workflow files, and README commands for Flutter and Rust tests. We did not run those separate toolchains, so this result says nothing about whether the engine, UI, bridge, or release packages pass their native suites.
The distinction matters because the root package.json identifies itself as repository tooling for commit rules. Its 48-package install is not the product build described in the README. A source build requires the Flutter SDK, Rust toolchain, Rinf CLI, fetched Flutter dependencies, and generated Dart bindings before flutter run or a platform release command. The 17-second success proves only that the small Bun-managed tooling layer installs cleanly.
Version 0.5.2 shipped one day before fresh integration reports
FluxDown v0.5.2 was published on October 1, 2026, and the repository was pushed again on October 2. GitHub showed 3,352 stars and 406 open issues and pull requests combined; a separate search counted 399 open issues. That is an active project with a heavy support queue. Release notes list fixes across the engine, packaging, proxy handling, diagnostics, and a Rust 1.99 linting change.
New reports show the cost of the wide platform matrix. Issue 743 demonstrates that Windows 0.5.2 misreads a fluxdown://download/?url= deep link as a relative download URL and fails before making a network request. Issue 740 reports that KDE browser interception from versions 0.5.0 through 0.5.2 does not start until the main window is opened. These reports target exact versions and flows, which makes them useful adoption checks rather than general complaints.
Android and antivirus reports need more caution. Two October 2 issues report an ARMv7 crash, while Windows users reported Kaspersky detections around versions 0.5.1 and 0.5.2. A detection report does not prove malware, and the issue threads we read do not establish a root cause. Download official assets, verify the supplied checksum, and evaluate any security alert under your own policy instead of dismissing or repeating it as a confirmed threat.
The privacy claim needs a feedback-pipeline review
The README says FluxDown uses no account and keeps download data local. The application architecture supports that claim: its API defaults to loopback and local state lives in SQLite. Yet public issue 745, created from the website feedback form on October 2, includes the submitter's contact value and IP metadata in the issue body. We are not repeating those values, but their publication deserves attention from the maintainers.
A local download manager can still have a separate website collection problem. Users with strict privacy requirements should file reports directly on GitHub until the feedback path stops publishing network and contact metadata. Teams deploying the server should also set FLUXDOWN_TOKEN, restrict port 17800, and remember that RSS and MCP automation can create tasks without the desktop interface. Local-first behavior depends on keeping those control routes local.
FluxDown is promising breadth, not proven speed in our lab
FluxDown covers more protocols and deployment shapes than most graphical download managers, and AGPL-3.0 gives buyers source access with reciprocal duties. We did not measure transfer speed, recovery accuracy, or memory use, so performance should be tested with your files and network.
Start with the v0.5.2 binary that matches your platform, verify its checksum, and exercise browser capture, pause and resume, and shutdown recovery before moving regular downloads. Server users should test token recovery and file deletion through both REST and MCP. FluxDown is worth that trial when one queue genuinely needs direct downloads, peer-to-peer protocols, streaming media, and agent control. If your job is a headless URL fetcher, aria2 reaches the decision with fewer moving parts.