nzbget: a C++ usenet downloader that runs on a NAS or a router
Efficient usenet downloader
At a glance
- What is it?
- NZBGet is a binary downloader for Usenet that reads nzb files, written in C++ and built for small devices as much as for desktops, with a web interface, an API and an extension system. It suits people who want a low overhead downloader on a NAS, a media player or a router, and the fork that now carries the project version numbers on a calendar scheme rather than the old sequence, which is the main thing to know when you read its documentation.
- Who is it for?
- Adopt NZBGet if you want a usenet downloader that fits on a NAS, a media player or a router and still exposes a web interface and an API for automation.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A downloader written to run on a device with little to spare
NZBGet is a binary downloader that downloads files from Usenet based on information given in nzb files. The project describes it as written in C++ and designed for performance and efficiency.
That efficiency framing is not a marketing claim so much as a statement about the target device. The README says NZBGet can run on almost any device, listing a classic PC, a NAS, a media player, a satellite receiver and a WLAN router, and the download area provides precompiled binaries for Windows, macOS, Linux, FreeBSD and Android, with the option of compiling from source for anything else.
That list is unusual. Most downloaders are written for a desktop and then happen to run on a NAS. This one is built small enough to be a service on a router, and the packaging reflects that. There is a Docker image published under the nzbgetcom organisation on Docker Hub alongside the LinuxServer.io variant, and there are dedicated packages for Synology DSM, ASUSTOR ADM and QNAP QTS, plus a TrueNAS SCALE entry in the app catalogue and a separate Android application.
The default branch is develop, and the main branch is where the build and docker workflows run. The top level of the repository shows the shape of the codebase: a `daemon/` directory for the background process, `lib/` for shared code, `webui/` for the interface, `cmake/` and `CMakeLists.txt` for the build, `platforms/` for the per-OS packaging, `docker/`, `scripts/`, `tests/`, `toolchains/`, and an `nzbget.conf` file at the root. There is also a `pubkey.pem`, which pairs with the code signing story described further down.
The licence is GPL-2.0-or-later, and the COPYING file sits at the repository root.
A fork that took over, and the version scheme it now uses
The project is a fork, and the documentation is honest about it. The README states that this is a fork of the original NZBGet project, formerly maintained by hugbug, and that the nzbget.com project continues where the original left off, in honor of and with respect for its maintainer of many years.
The consequence for users is that there are two histories of documentation, two sets of behaviours and, in places, two incompatible extension APIs. The documentation section lists extensions twice: one page for the V2 extensions, described as v23 and above, and a separate legacy page for V1 extensions, v22 and below. If you are reading an old guide that describes writing an extension, check which version it targets before following it.
The version numbering is the other thing to notice. The listed releases are v26.3 from 2026-08-27 and v26.2 from 2026-06-18, alongside a release literally named `testing` dated 2026-10-16. The old scheme was a running sequence such as v21, v22, v23, and the new one is a year and month. The migration notes in the README point to a discussion for migrating from NZBGet v21 or older and a separate issue for migrating from older Docker images, which tells you that both an application upgrade path and a container upgrade path need attention.
The `testing` tag is worth understanding. It is a published release channel alongside the versioned ones, which is how you would try a build before committing to it on a machine that is also serving files.
The web interface, the API and the extension system
Three extension points are documented, and they serve different purposes.
The web interface is the `webui/` directory in the repository, and it is how you configure and monitor the daemon. The documentation index lists a how to use guide, a performance tips page, a page on RSS feeds and a separate API reference.
The API is what makes NZBGet scriptable, and it is a first-class part of the documentation rather than an afterthought. That is what lets the daemon live on a router with no shell access and still be driven by something on your network.
Extensions are the third point, and the V1 to V2 split makes them the trickiest. The two documentation pages are separated by the v23 boundary, which tells you the extension contract changed in that release and that extension code written for one side will not run on the other. If you run an existing extension, that boundary is the thing to check on upgrade.
RSS feed support is documented separately from the API, which is a hint about how the downloader is used in practice. A downloader that pulls from Usenet is usually fed by something, and the RSS path is how that something arrives.
The `unpackers.env` file at the repository root and the `scripts/` directory suggest the extraction side is a defined part of the pipeline rather than an afterthought, and the `tools` in `nzbget.conf` are where a post-processing script is wired in. How the unpackers are packaged and licensed is not described in the README, which is a gap worth filling from the source before you rely on it.
Supported platforms, architectures and package managers
The installation table is the most useful page in the README, because it is unusually specific about what is supported where.
| Platform | Installation | Supported architectures / OS versions | |---|---|---| | Windows | Releases, Winget, Chocolatey | Windows 7, 8, 10 and 11 (32-bit or 64-bit) | | macOS | Releases, Homebrew | macOS Mojave 10.14+ (Intel) / macOS Big Sur 11+ (Apple Silicon) | | Linux | Releases, DEB/RPM, Repositories, Flatpak, Snap | Linux kernel 3.2+, x86 (32/64-bit), ARM 32-bit (armel, armhf), ARM 64-bit (aarch64), PowerPC (ppc6xx), RISC-V 64-bit (riscv64) | | FreeBSD | Releases | FreeBSD 13.0+ (x86-64 / aarch64) | | Docker | Official images, LinuxServer.io | x86-64 / arm64 / armv7 | | Synology NAS | SynoCommunity package | DSM 7.x / 6.x / 3.x | | ASUSTOR NAS | nzbget-asustor, App Central | ADM 4.3+ | | QNAP NAS | Package manager, Manual installation | QTS 4.1.0+ (x86-64 / x86 / arm_64 / arm-x19 / arm-x31 / arm-x41) | | TrueNAS SCALE | TrueNAS App catalog | x86-64 (amd64) | | Android | Releases, Android app | Android 5.0+ (arm64 / armv7 / x86 / x86) |
Three things stand out. The Linux architecture list includes RISC-V 64-bit and PowerPC, which is a sign of the project being built for embedded devices rather than only for the usual server silicon. The QNAP row is more granular than the others, listing six QTS variants, which is what a package that has to be built per model looks like. And the Docker row covers armv7, which matters for older ARM boards.
Windows still lists 7 and 8 alongside 10 and 11, and the Android floor is 5.0. Both of those are legacy floors that say more about the age of the supported device base than about the current feature set.
There is no install command to copy here. The README points to releases, to the platform documentation under `platforms/`, to the Docker Hub images and to the various package managers, and the per-platform details live in files such as `platforms/windows/pkgs-info.md` and `platforms/macos/brew-info.md`.
Windows binaries are code signed through SignPath
The code signing policy is stated plainly and it is a meaningful detail for a downloader that people run on a home machine.
For the Windows release, free code signing is provided by SignPath.io, with the certificate provided by the SignPath Foundation. The `pubkey.pem` file at the repository root belongs to that arrangement.
The reason this matters in practice is that an unsigned binary triggers SmartScreen on Windows, and a Usenet downloader is exactly the kind of program a user downloads from a website rather than from a package manager. The signed Windows release removes that friction, and the fact that the certificate is donated rather than purchased means the project gets it without a direct cost.
The same trust argument is why the Docker images and the NAS packages are separate artefacts worth checking against the official ones. The README lists both official images and the LinuxServer.io variant for Docker, and for ASUSTOR it lists both a dedicated repository and the App Central entry. Each of those is a third party that repackages the project, and each will have its own release cadence relative to the v26.x line upstream.
Security issues have their own path. The README routes security reports to a SECURITY.md file in the repository, separately from the GitHub Discussions board used for questions and help and the issue tracker used for bugs and feature requests. That separation is standard practice and worth noting for a project that handles untrusted input from the network.
Building from source with CMake and running the test suite
Building NZBGet yourself is a CMake job rather than a makefile one, and the repository is set up for it. There is a `CMakeLists.txt` at the root, a `CMakePresets.json` for configured builds, a `cmake/` directory for the module files, and a `toolchains/` directory for cross compilation. The presence of `.clang-tidy` and `.clangd` files shows the C++ code is linted and that the editor is configured for it, and `scripts/` holds the helper scripts the build expects.
The README points to `INSTALLATION.md` for the build instructions, so the exact toolchain invocation is documented there rather than in the summary. What the repository layout makes clear is that a source build is a real engineering exercise rather than a single configure step, which is the expected trade for a program that has to run on a router.
Tests live in `tests/` and the CI configuration shows three separate workflows. One is the tests workflow, which the badge shows running against the develop branch. The others are a build workflow and a docker build workflow, both running against the main branch. Splitting the branches that way tells you something about the release flow: the packaging and container images are built from main, while the test job tracks the integration branch.
The test suite itself is worth noting for a project of this size, since a C++ downloader that has to be correct about segment verification and file reassembly is a natural candidate for a large test corpus. The README does not describe the test coverage, so that is a question for the source.
Contributions are accepted from developers and users, with the setup, coding rules and pull request workflow in `docs/CONTRIBUTING.md`. The project also has an AI policy document, and the README states that AI-assisted contributions are allowed but only if they follow that policy, which is a more specific commitment than most projects make.
Editorial conclusion
Adopt NZBGet if you want a usenet downloader that fits on a NAS, a media player or a router and still exposes a web interface and an API for automation. Do not adopt it if you are moving up from a recent v22 or v21 install without reading the migration notes, because the extension API changed and the configuration is not the same, and check first that the platform you want is on the supported list, since architectures range from riscv64 and ppc6xx to armv7 and the release channel carries a testing tag alongside the versioned ones.
Frequently asked questions
What is NZBGet and what does it do?
It is a binary downloader that downloads files from Usenet based on information given in nzb files, written in C++ and designed for performance and efficiency. It comes with a web interface, an API reference and an extension system.
Can I run NZBGet on a NAS or a router?
Yes. The README says it can run on almost any device including a NAS, media player, satellite receiver or WLAN router, and there are packages for Synology DSM, ASUSTOR ADM, QNAP QTS and TrueNAS SCALE, plus official Docker images covering x86-64, arm64 and armv7.
Is the current NZBGet the same project as the original one?
It is a fork. The README describes nzbget.com as a fork of the original project formerly maintained by hugbug, continuing where the original left off. The version scheme also changed, with releases now named v26.3 and v26.2 rather than the old running sequence.
How do extensions work in NZBGet?
Extensions are documented in two separate pages, one for the V2 API used in v23 and above and one for the legacy V1 API used in v22 and below. That split marks a breaking change in the extension contract, so extension code has to be checked against the version you run.
Are the Windows builds of NZBGet signed?
Yes. The code signing policy states that free code signing for the Windows release is provided by SignPath.io, with the certificate provided by the SignPath Foundation, and a pubkey.pem sits at the repository root.
Is NZBGet still being maintained?
The repository is not archived and the last push was on 2026-10-20. The listed releases are v26.3 from 2026-08-27, v26.2 from 2026-06-18 and a testing release from 2026-10-16, under a GPL-2.0-or-later licence.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nzbgetcom-nzbget)Was this useful?