Decypharr, a media gateway that makes Arr apps speak Debrid and Usenet

It speaks the download client protocols the Arr apps already know

Decypharr is a media gateway for Debrid services and Usenet, written in Go. The problem it addresses is narrow and real. Sonarr, Radarr, Lidarr and the rest of the Arr family are built around the assumption that they talk to a download client over a specific protocol, and the download client they expect is either a torrent client or an NZB client running on the same network.

Decypharr removes that assumption. It provides a unified interface for Sonarr, Radarr and other Arr applications to access Debrid providers and Usenet streaming, by mocking the qBittorrent and SABnzbd APIs that those applications already support. From the Arr app's point of view, Decypharr is a download client. Behind it, the traffic goes to a Debrid provider or to Usenet instead of to a local torrent client.

The listed features follow from that design. Multiple Debrid and Usenet providers are supported through a single interface, so the provider is a configuration choice rather than a property of the whole setup. Direct Usenet streaming happens over NNTP with no separate download client required. And the same libraries can be exported over read-only NFSv4 and SMB servers, including custom virtual folders, which is how a media library that lives in a provider's storage becomes visible to the rest of your infrastructure.

The five supported Debrid providers are Real Debrid, Torbox, Debrid Link, All Debrid and Premiumize. The licence is MIT and the project is a small Go module, github.com/sirrobot01/decypharr, with the current release v2.7 dated 2026-10-08 and the last push on 2026-10-10.

Usenet without a download client, straight over NNTP

The Usenet path deserves separate attention because it changes the shape of the deployment.

Direct Usenet streaming via NNTP means no separate download client is required. In a conventional setup, an Arr app hands an NZB to a running NZB client, the client downloads it over NNTP to a local disk, and the Arr app then imports the result from a watch folder. With Decypharr in the middle, the Arr app still thinks it is talking to a download client, and the gateway does the NNTP conversation and the assembly itself.

The Go dependencies show how that is assembled rather than delegated. The project pulls in github.com/Tensai75/nzbparser and github.com/Tensai75/subjectparser for reading NZB and subject lines, github.com/javi11/sevenzip for archive handling, and github.com/klauspost/compress together with github.com/mnightingale/rapidyenc for decompression. That is a complete local stack for turning a Usenet posting into a file.

The torrent side sits alongside it, with github.com/anacrolix/torrent as the client library, plus the anacrolix ecosystem of DHT, chansync, go-libutp and btree as indirect dependencies. The Dockerfile notes that native libutp is used to avoid large Go allocations during peer connection setup, which is a detail about the cost of establishing a torrent connection rather than about the feature set.

The practical difference between the two paths is where the bytes land. The Usenet path can stream without a local download client, while the Debrid path always involves a third party service that holds the links.

Read-only NFS and SMB share the same library

The fourth feature is the export side: read-only NFSv4 and SMB servers for the same libraries, including custom virtual folders.

This is what makes Decypharr more than a download client shim. The Arr applications still use their own local library layout and their own import mechanism, but the media they import from can be fetched from a provider at the moment it is needed. Read-only NFSv4 and SMB give the rest of your stack, the dashboards, the media servers, the other tools, a filesystem view of the same content, without the content having to be copied to local disk first.

The implementation depends on FUSE. The Go dependencies include github.com/hanwen/go-fuse/v2 and github.com/winfsp/cgofuse, which are FUSE libraries for Go, plus github.com/sirrobot01/facetfs, a virtual filesystem library from the same author, and github.com/sirrobot01/appendstore for append-only storage. The Dockerfile installs fuse-dev in the builder stage, which is the C-level dependency needed to build those packages with CGO enabled.

The two export protocols are exposed on optional ports. NFSv4 is published as 2049 to 20490 over TCP, and SMB as 445 to 1445 over TCP, with the compose file noting that Windows clients require host port 445. Both are commented out in the example configuration, which is the right default since exposing an SMB port on a home network deserves a deliberate decision rather than a default.

The container needs SYS_ADMIN, FUSE and an unconfined profile

The recommended deployment is Docker, and the compose file in the README is the whole setup:

services:
  decypharr:
    image: cy01/blackhole:latest
    ports:
      - "8282:8282"
    volumes:
      - /mnt/:/mnt:rshared
      - ./configs/:/app
    restart: unless-stopped
    devices:
      - /dev/fuse:/dev/fuse:rwm
    cap_add:
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined

Three things in that file deserve attention before you copy it.

The devices entry passes /dev/fuse into the container, which is what the FUSE-based filesystem layer needs to present the NFS and SMB exports. The cap_add of SYS_ADMIN grants the capability that FUSE operations require. And the security_opt of apparmor:unconfined turns off the AppArmor confinement for the container, which is normally there for a reason.

The /mnt mount with the rshared propagation option is what lets the exported filesystems reach the host's mount namespace, and the ./configs mount is where config.json has to live, as the comment in the compose file states. The web interface listens on port 8282.

So the honest summary is that Decypharr asks for a fairly privileged container in order to serve filesystems. That is a normal requirement for a FUSE server and it is the kind of thing to weigh on a machine that is not also running your most sensitive workloads.

The build pulls in CGO, cross compilation and a healthcheck binary

The Dockerfile shows how the project is built, and it is a more involved build than a pure Go binary.

It is a multi-stage build on Alpine. The first stage uses tonistiigi/xx for cross compilation, and the builder installs clang and lld plus gcc, g++, musl-dev, libc-dev and fuse-dev through the xx toolchain, which is what allows the CGO parts to compile for a target architecture other than the build host. The main binary is built with CGO_ENABLED=1 and xx-go, with the version and channel stamped into it through ldflags, and the fuse-dev package explains why CGO is mandatory here rather than optional.

A second binary, the healthcheck, is built without CGO as a plain cross compile, which is the standard approach for a probe that has to run in an environment without the C library. The final image is alpine:latest with the version and channel as labels.

The module itself requires Go 1.26.5. The web front end is built with Tailwind CSS 4 and daisyUI, with terser for minification, and the development loop uses air for hot reload, driven by the scripts in package.json. The router is go-chi, sessions use gorilla/sessions, scheduling uses both gocron and robfig/cron, logging is zerolog with lumberjack for rotation, and there is a rate limiter from go.uber.org, which is sensible for a service that proxies requests on behalf of several providers.

Where Decypharr fits, and what it deliberately leaves out

The alternative approach is to connect each Arr application directly to a provider, either by running a local torrent or NZB client that talks to the Debrid service, or by using the provider's own tooling. The difference in approach is that the Arr apps keep their existing download client configuration, and everything provider-specific is concentrated in one place with one interface.

For someone who already has a well-tuned local download client and a healthy library on local disk, that concentration may be unnecessary. Decypharr adds a network hop and a privileged container in exchange for provider flexibility and for the NFS and SMB exports, which a local client does not give you.

The tool also has limits that follow from its architecture. It is a gateway for remote links, not a local media manager, so it does not replace the local library that your Arr apps and media servers already read. The exports are read-only, so the library cannot be written to through them. And the provider list is fixed in the code, so a new service is not something you configure but something the project adds.

One point is worth stating plainly and is not the project's responsibility. Debrid services and Usenet providers have their own terms, and what is legitimate to download through them is a question about your provider and your jurisdiction, not about the gateway. The tool routes links; it does not decide what they point at.

Editorial conclusion

Decypharr suits a home-lab operator who already pays for a Debrid service or has a Usenet provider and wants their Arr applications to use it without a separate download client, and it does not suit someone who wants direct access to their own local files, since it is a gateway for remote links rather than a local library manager. Before you deploy it, read the compose file carefully, because the container needs SYS_ADMIN, /dev/fuse and an unconfined AppArmor profile, and confirm your Arr apps can point at a configurable download client host and port rather than a fixed local path.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sirrobot01/decypharr on GitHub