A NAS is a good place to keep a collection. Making that collection easy to build, recognise and browse takes a little more than a shared folder. That is where prdb-fab and prdb-viewer come in: two open source applications you run yourself, with prdb.net supplying the catalogue and identification behind them.
Both use Docker Compose as their supported deployment method. If your home server already runs containers alongside its storage, they fit naturally into that setup. Both also require a prdb.net API key to complete their setup. The applications are open source; access to the prdb API is provided by a paid API plan.
prdb-fab: from wanted list to organised library
The name stands for Fetch and Build. prdb-fab connects your prdb account, Usenet indexers and SABnzbd, then brings the process of finding, downloading and filing content into one web interface.
It keeps local catalogues of prdb records and indexer releases, uses prdb to identify releases, and lets you send an eligible release to SABnzbd. Once the download finishes, it collects the video files and files safely identified arrivals into a sorted library. Uncertain files go to a review queue so you can decide what they are.
The resulting library uses a Jellyfin-compatible Movies layout, with a movie.nfo
file and artwork where available. You can browse your wanted list, sites and actors,
follow downloads, and see what needs attention on the Status page. For unattended
operation, you can enable automation rules for matching wanted videos. Start with a
manual download to check your paths before turning those rules on.
prdb-fab is a single-user application with its own password. Its first-run wizard checks the prdb key and walks you through the other connections. SABnzbd and indexers can be added later, but downloading needs a working SABnzbd installation, a Usenet provider and at least one indexer with API access. A prdb subscription supplies the database connection; those other services remain separate.
The project describes itself as early software. Its README explains the current download, filing and automation behaviour in detail.
prdb-viewer: give existing files a browsable home
If you already have a collection, prdb-viewer starts there. Mount your video folders, connect the installation to prdb, and let it scan and identify the files. It brings local media together with catalogue information, performer pages and previews in a searchable library.
The viewer supports browser playback, individual accounts and personal playback state. It can recognise multiple encodes of the same work and offer identification from one copy for the others. An administrator review workflow handles files that cannot be identified confidently. Playback depends on what the browser can play, so check your actual file formats with the devices you plan to use.
Source libraries are mounted read-only. prdb-viewer keeps its database and derived
data in a separate writable /data mount, leaving your original media untouched.
The first administrator is created using the project’s documented bootstrap
authorization procedure, followed by guided setup for the API key and library.
Follow the Docker Compose deployment instructions
for those steps.
Two applications, one useful collection
You can use either project on its own, or give each a role in the same home server:
| Application | Its job | Access to your media |
|---|---|---|
| prdb-fab | Find releases, coordinate downloads and build the library | Write access to downloads and the destination library |
| prdb-viewer | Identify, browse and play existing library files | Read-only access to library folders |
| prdb.net | Supply catalogue information and identification through the API | Each application connects using a prdb API key |
For a combined setup, let prdb-fab write to your library folder and mount that same folder read-only in prdb-viewer. Keep their application data in separate directories. The connection between the two is the shared media folder and their use of prdb; each application maintains its own state and configuration.
Made for the home server crowd
TrueNAS, Unraid, OpenMediaVault and other NAS solutions are familiar territory for self-hosters who want storage and applications on the same machine. The practical requirement here is a working Docker Compose deployment path on your chosen system, with storage that the containers can access.
On Docker-based TrueNAS releases, a Custom App installed through the YAML editor can run a Compose definition. On Unraid or another NAS, use the Compose tooling available for your installation and adapt the host paths and permissions. These projects ship Compose configurations; you do not need to wait for a dedicated NAS catalogue entry. TrueNAS documents its workflow in Installing Custom Apps.
Give each app persistent local storage for /data, choose a free host port, and set
PUID and PGID to an identity with the appropriate access to your media. Keep SQLite
application data on local storage rather than an SMB or NFS share. Your media library
can live on NAS storage, with the mount arrangement described in each project’s docs.
Self-hosting keeps the applications and media on your hardware, while catalogue and identification requests still go to prdb.net. In prdb-fab, review Settings → Reporting: fulfilment reports and confirmed file assignments have separate switches and are enabled by default. The privacy documentation describes what each sends.
Pick your starting point
Already have files you want to browse? Start with prdb-viewer. Want to connect your wanted list to a download-and-filing workflow? Start with prdb-fab.
You will need an account with API access for either application. You can create a prdb account and compare the API plans before configuring the connection.
For a concrete NAS setup, continue with our guide to installing prdb-fab as a TrueNAS Custom App.