SABnzbd: the repair step is the whole product

Add an .nzb and nothing else is required

The product claim is deliberately narrow. SABnzbd is an open source binary newsreader written in Python, described as free and easy to use, and the whole workflow is that you add an .nzb. From there it takes over: the download runs, the files are verified, damaged segments are repaired, archives are extracted, and the result is filed away, all with zero human interaction. Two supporting pieces come with that promise. There is a setup wizard for the first run, and there are self-analysis tools that verify your own setup, which matters for a tool whose failure modes are usually a bad par2 or a missing unrar rather than a bug in Python. The repository is not archived, the default branch is develop, and the recent tags are 5.1.2 on 2026-08-25, 5.1.3 on 2026-09-08, and 5.2.0Beta1 on 2026-09-22.

Two external binaries that pip cannot install

There are four requirements, and two of them are not Python packages.

python3 -m pip install -r requirements.txt

The first is an interpreter, listed as python, meaning Python 3.10 and above and often called python3. The second is the module set in requirements.txt, installed with the command above. The third is par2, for which a multi-threaded par2 installation guide is linked, since the repair step is only as good as the repairer. The fourth is unrar, with a specific warning: get the official non-free version. That distinction matters because the freely available unrar source is not the one the project wants you running, and there is a separate guide for installing the modules without a package manager. Optional dependencies are handled the same way, by pointing at requirements.txt. If you previously ran SABnzbd from a Linux package, the README notes you probably already have all of this.

From source the command line is one flag deep

Running from source is a single command, and the flag is not accidental.

python3 -OO SABnzbd.py

The -OO option runs the interpreter at optimisation level two, which strips docstrings and assertions from the loaded modules, and for a long-running service that is the difference between a smaller memory footprint and a larger one. A background invocation adds a daemon flag and an explicit configuration file.

python3 -OO SABnzbd.py -d -f /path/to/sabnzbd.ini

Translations are a separate step rather than a runtime concern, since the message catalogues are compiled ahead of time by a script in the tools directory: python3 tools/make_mo.py. Everything else on the command line is documented at length on the project wiki rather than in the README, which is a reasonable division for a tool with this many options. The repository mirrors the platforms it targets with separate linux, macos, and win directories, plus a snap directory and a portable.cmd for running from a Windows folder without installation. Because the entry point is a single script, the same command works on all three platforms once the dependencies and the two repair binaries are in place, which is why the platform directories hold packaging and integration pieces rather than a different application.

The branch policy still describes version 1.1.x

The repository section describes a simplified GitFlow with clear rules, and the rules are the useful part. The master branch contains only stable releases and is the branch intended for end users. The develop branch is the integration target and is explicitly not intended for end users. Release and maintenance branches follow the version they release, and feature and bugfix branches are temporary and based on develop. Four constraints make the model work: a stable release merges into master simply because the release branch is always right, master is never merged back into develop, develop is never rebased onto master, and release branches branch from develop only. Cherry-picking is one-directional, from develop to a release branch, since a bugfix made for a release is specific to it. The version numbering rule is that a 1.0.2 will not be released once a 1.1.0 exists. Two practical consequences follow for anyone cloning the repository. The default branch is develop, so a plain clone gives you the integration branch and not a stable release, and the 1.1.x example in that description is historical text rather than the current scheme, since the recent tags are in the 5.x range. If you want the stable line, take master or a release tag instead.

requirements.txt pins what has broken before

The dependency file opens with a comment that explains its own policy: not every sub-dependency is listed, only the ones known to cause trouble. Everything that is listed is pinned exactly, including apprise for notifications, sabctools for the article handling, CT3 for the indexer, configobj, feedparser, rarfile, guessit for filename parsing, babelfish for language detection, and hachoir for metadata. Three entries carry their own explanations. puremagic is left version-less for Python 3.11 and below and pinned above that, which is a marker-based workaround rather than a tidy constraint. cryptography is open-ended at 3.0 or newer because recent versions require Rust, with a note that older pre-Rust versions still work and carry security implications. And two JSON libraries ship together, ujson and orjson, with orjson described as twice as fast but Rust-dependent, so ujson or the standard library module remains the fallback.

Four files are exempt from linting, each for its own reason

The lint configuration is worth reading because the exemptions are documented rather than silent. Black and Ruff both target py310 with a line length of 120, and Ruff excludes the tools directory and sabnzbd/utils while declaring T and TT as builtins, which is how the type-checking comment convention is recognised. The rule selection covers the usual error, warning, and pyupgrade families plus comprehension and complexity checks, while the ignore list keeps line length and several upgrade rules off. Four files then get per-file exemptions.

[tool.ruff.lint.per-file-ignores]
# We want to keep the start-up import checks
"SABnzbd.py" = ["F401"]
"sabnzbd/__init__.py" = ["F401"]
# Dynamic symbol injection during version/build setup
"builder/common.py" = ["F821"]
# macOS Bonjour symbols resolved via ctypes/dylib at runtime
"sabnzbd/utils/pybonjour.py" = ["F821"]
"sabnzbd/utils/sleepless.py" = ["F821"]

The first two keep unused imports that exist to fail fast at startup. The third allows undefined names injected during version and build setup. The last two cover symbols that only exist at runtime, resolved through ctypes on macOS. Pytest is configured with three markers, config, platform, and fake_fs.

Two READMEs, a translation pipeline, and a privacy statement

The root of the repository carries both README.md and README.mkd, which is a small inconsistency that tells you the project has been packaged for many years rather than rewritten recently. The rest of the tree explains the structure. po/ holds the translation catalogues, .tx/ holds the Transifex configuration, and tools/make_mo.py compiles them, so localisation is a build step. The application code is split by role, with sabnzbd/ for the core, context/ for the interface layer, interfaces/ for the concrete back ends, email/ for notifications, and builder/ for packaging. licenses/ sits beside COPYRIGHT.txt and the GPL2.txt and GPL3.txt files, which is consistent with the licence metadata recording no single identifier. A .git-blame-ignore-revs file at the root records the revisions to keep out of blame output, which tells you the project has run repository-wide formatting passes and prefers to keep authorship readable afterwards. Two policy statements close the file. The privacy policy says no information is transferred to other networked systems unless specifically requested by the user or by whoever installs or operates it. Windows builds are code signed for free by SignPath.io with a certificate from the SignPath Foundation.

Editorial conclusion

SABnzbd fits anyone who already has Usenet access and wants the repair and unpacking handled for them, and it runs on Linux, macOS, and Windows from the same script. Before installing, confirm the two external binaries are available, since par2 and the official non-free unrar are outside pip and the project is explicit that you supply them. If you are reading the branch policy, ignore the 1.1.x example: it predates the current versioning, and the default branch is develop, not master.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sabnzbd/sabnzbd on GitHub