Every download on this page except the Android APK is now built and attested on GitHub, a faster first download on providers with slow connections, a Sonarr/Radarr setup that leaves finished downloads alone, security updates, and fixes from three review passes.

Which file do I download?

On Unraid there is nothing on this page to download. The Community Applications template fills in port 6789, the three paths and the Unraid user IDs, so there is nothing to write by hand.

Already running the Docker image, on Unraid or anywhere else? Also nothing to download: the tag latest now points at 1.9.0, so update the container the way you normally do (on Unraid that is the Docker tab, Check for Updates, Apply Update).

The Windows on ARM build is a beta: it is still in testing, and it is not as stable or as proven as everything else on this page - it ships with each release so that people on these machines can try it and tell us what breaks. It is a native ARM64 build rather than x64 under emulation, so it should be quicker and easier on the battery, but if anything at all misbehaves the windows-x64 installer runs on these machines too and is the proven one. Like every Windows download here it is not yet code-signed, so expect SmartScreen's "Windows protected your PC" and an elevation prompt naming an unknown publisher, and expect Defender to be more suspicious of it than of the x64 build - that combination has not been exercised on ARM64 either. It is also outside the update check: the in-app updater will not offer it a new version, so watch this page instead.

The Linux .deb and .rpm packages are also a beta. They install the daemon as a system service with its own user and a data directory under /var/lib/nzbfast, and they enable it without starting it, because there is nothing to download until you have added a provider. Both were installed and upgraded on Debian and Fedora before shipping, but they are new, they are not in any distro's own repository, and the version says so: 0beta1 and 0.beta1 both sort BELOW the eventual release revision, so upgrading to the finished package works normally when it lands. If you would rather not be the one to find the rough edges, the linux-x64 and linux-arm64 tarballs are the same program and have shipped for months.

The QNAP .qpkg is a beta of a different kind: it has never been run on a QNAP. Nobody on the project owns one. It is built with QNAP's own QDK, its install decisions are tested against simulated NAS layouts and the built package is taken apart and checked before release, but none of that is a real NAS booting it - so it is offered in the hope that somebody will try it and tell us. Install it through App Center, the gear icon, Install Manually; one file covers both Intel and 64-bit ARM models. Your settings and downloads are normally kept outside the app's own folder, so removing the package leaves them where they are; the exception is a NAS where no shared folder was usable at install time, in which case setup says so on screen and puts them inside the app folder, where an uninstall does take them with it. An issue saying what happened either way is the most useful thing a QNAP owner can send us. The Docker image on Container Station remains the proven path.

Run uname -m if you are not sure which Raspberry Pi download you need: aarch64 means the 64-bit OS, so take the ARM64 file. Only armv7l (or armv6l) wants the beta 32-bit build - and that one is beta because it has not yet been through a release on real Pi hardware, so it is not offered by auto-update. Update it by downloading the next one by hand.

The FreeBSD build is the least proven beta here: nobody has run it on a real FreeBSD machine. It is built inside a FreeBSD virtual machine on every release, and that same binary downloads a synthetic release over loopback before the file is packaged, so it is not shipped untried. But a virtual machine is not a NAS: no real disks, no ZFS pool, no jail. It is x86-64 only, it needs FreeBSD 14.3 or newer, and it does not reach TrueNAS CORE, which is FreeBSD 13 and now out of support. Unpack it, read the README inside, and there is an rc.d service script in there so sysrc nzbfast_enable=YES works the way you would expect. Like the other betas it is outside the update check. If you run FreeBSD, an issue telling us what happened - working or not - is worth more to this build than anything else we could do to it.

The Android build is a beta in the fullest sense. It is the download engine with a phone front end, ARM64 only, and it is not on Google Play - you install the .apk yourself, which means Android will warn you about installing from an unknown source and you have to allow it for your browser or file manager. It is signed with our own key rather than a store one, so that warning is expected; what matters is that the same key signs every future build, so updates install over the top instead of asking you to uninstall first. Unlike the other betas it does tell you when a new version is out: the app asks its own engine once a day, when you open it, and puts a card at the top of the screen with a link to the releases page. It will never install anything - Android does not let an app replace itself without a permission we do not ask for - so the new .apk is still a download you start. If you try it, an issue telling us what your phone did is worth more than anything else you could send us.

Everything named nzbfast-updater-*, plus latest.json, latest.json.sig and SHA256SUMS, is machine-only. You do not need to download those.

Every download built where you can check it

In 1.8.0 the main downloads moved onto GitHub's own runners. Now the rest have too: the .deb and .rpm packages, the Synology and QNAP packages, and the Linux armv7, FreeBSD and Windows ARM64 betas. Each file is built from the public repository, has an attestation (.intoto.jsonl) and a software bill of materials (.spdx.json) beside it, and gh attestation verify <file> --repo nzbfast/nzbfast checks that the file you downloaded came out of that build. The binaries inside the .deb, .rpm and NAS packages are the same bytes as the attested Linux tarballs, and SHA256SUMS covers every file. The one exception is the Android APK, an experimental beta, which is still built and signed on our side because its signing key never leaves one machine.

Faster first download on providers with slow connections

nzbfast starts a new install at 25 connections and raises that once it can see the extra connections help. On providers where each connection is slow (a few MB/s), 25 connections never moved fast enough for that check to run, so a fresh install's first download stayed at 25 for its whole length. On a fast line with slow connections that check now runs, and the cap climbs as far as the connections keep paying off. Slow lines are unchanged. Thanks to the reporter for the measurements that found it (GitHub #103).

Sonarr, Radarr and other apps

• The setup answer "Sonarr, Radarr or another app drives it" now also turns off renaming, the Trash and Spotnet scanning, so finished downloads are left for the app to name, file and clean up. Nothing changes until you press Apply, and you can untick any row (GitHub #102).
• nzbfast import-sab --arr applies the same setup from the command line, for installs set up by importing SABnzbd that never see the setup card. Settings you already saved are kept.
• A release name ending in a one-word tag, like -nzbfast, keeps that tag when it is renamed instead of being read as a release group.
• Spotnet scanning now follows the indexing switch on a fresh install, so a new install scans nothing until you turn indexing on. An install that already indexes keeps its spots (GitHub #100).

Security

• A fresh install set up with nzbfast import-sab from a SABnzbd setup that has an archive passwords file could start without an API key, leaving its control API open on the network. It now creates a key as every other fresh install does.
• Dependency updates fix eleven published advisories, including the TLS libraries every news-server connection uses.
• Logs and diagnostic reports blank Sonarr/Radarr API keys and list-source tokens.

Fixes

• With early file publishing on, cancelling or cleaning up a job could delete a file that had replaced the published copy at the destination. nzbfast now checks a file is still its own copy before removing it.
• A cleanup list naming rar or 7z could delete the volumes of a job still waiting for its password. They are now kept until the job is unlocked.
• A job whose archives use more than one password, or mix password-protected 7z and RAR sets, now unlocks and finishes.
• Turning off "do this when the queue finishes" at the wrong moment could still run the action.
• A disk-space or quota hold now clears when space returns while the queue is paused.
• NZBGet-API clients adding a job by URL keep their post-processing settings and add-to-top choice.
• Retrying or recategorizing a finished job files it in the category's folder.
• On Windows, files whose names had to be cleaned up, and a relative --out folder, now land in the folder they belong in.
• Several faults in RAR, 7z, ZIP and PAR2 handling found in review, none of them reported by users.

Windows code signing

The SignPath Foundation has approved nzbfast for its free code signing for open source projects, and the certificate is being issued. Until it is in place, the Windows downloads on this page are not code-signed, so Windows SmartScreen will show a "Windows protected your PC" warning and the installer will name an unknown publisher. Choose More info, then Run anyway. The SHA256SUMS file on this release, and the attestation beside each Windows file, let you check that what you downloaded is what we published.