NZBHydra2 Beginner’s Guide

NZBHydra2 is a meta search tool for Usenet that queries multiple NZB indexers simultaneously and returns unified, deduplicated results through a single web interface.

If you have ever opened three or four indexer tabs, searched the same release on each one, and manually compared results, you already understand the problem NZBHydra2 solves. It sits between your indexers and your download clients, acting as a centralized Usenet search interface that handles the querying, merging, and filtering for you.

The tool is free, open source, and self-hosted. That means it runs on your own machine or server, and your search traffic stays under your control. For archival data organizers and anyone building a home lab automation stack, that matters.

This guide walks through what NZBHydra2 does, how to install it with Docker, how to connect it to your indexers and download clients, and how it fits into a broader automation workflow. We also cover privacy basics and compare it to similar tools so you can decide whether it belongs in your setup.

What NZBHydra2 Does in a Usenet Setup

NZBHydra2 searches raw indexers like Binsearch and NZBIndex alongside any newznab-compatible indexer, merges the results, removes duplicates, and surfaces everything in one interface. The value is consistency: one query goes out, one result list comes back.

How a Meta Search Tool Differs From a Single NZB Index

A single NZB index holds its own database of Usenet articles. When you search it, you only see what that index has retained and indexed. Coverage gaps are common, especially for older or niche content.

A meta search tool does not store its own index. Instead, it forwards your query to multiple indexers in parallel and aggregates whatever they return. NZBHydra2 fits this model exactly, functioning as a unified search layer above your existing indexers rather than replacing any of them.

The practical difference is coverage. Searching five indexers through one interface consistently surfaces more results than searching any single source.

How NZBHydra2 Queries Multiple Indexers From One Place

When a search is submitted, NZBHydra2 sends the query simultaneously to every configured indexer source. Each indexer returns its own results, and NZBHydra2 merges those results into a single list. Duplicates are identified and flagged based on configurable criteria like file name, size, and age.

NZBHydra2 natively supports:

• Binsearch (raw Usenet search)
• NZBIndex (raw Usenet search)
• Anizb (raw Usenet search)
• Any newznab-compatible indexer (structured, API-driven search)
• NZBmegasearch-style aggregation (legacy compatibility)

Newznab indexers return structured metadata including media IDs, which makes them far more useful for automation. Raw indexers like Binsearch work for manual searches but lack the metadata that automation tools rely on.

When To Use NZBHydra2 Instead of Manual Downloads

Manual downloads make sense when you have one indexer and know exactly what you are looking for. Once you have two or more indexers, the comparison work becomes tedious fast.

NZBHydra2 earns its place when:

• You use three or more indexers with overlapping but inconsistent coverage
• You want to feed a unified search endpoint into Sonarr, Radarr, or similar automation tools
• You need search history, stats, and indexer performance tracking in one place
• You want to avoid exposing individual indexer API keys to multiple downstream apps

For pure beginners with a single indexer, it adds setup complexity without much payoff. The tool rewards users who are already managing multiple sources.

Core Features, Limits, and Trade-Offs

NZBHydra2 comes with a feature set that goes well beyond basic aggregation. It includes stats tracking, RSS feed support, multi-user authentication, and deep configuration options that can feel overwhelming at first. Knowing which features matter early and which ones to ignore until later makes the initial setup much less intimidating.

Search Merging, Duplicate Handling, and Advanced Filtering

The merge and deduplication logic is one of NZBHydra2’s most useful features. When multiple indexers return the same NZB file, NZBHydra2 recognizes the duplicate and groups them rather than flooding the result list with identical entries.

Advanced filtering lets you restrict results by:

• Age (NZB age cutoffs to exclude outdated posts)
• Size (minimum and maximum file size ranges)
• Indexer (restrict certain queries to specific sources)
• Required or forbidden words in the title

These filters apply globally or per indexer. Fine-tuning them takes time, but the payoff is cleaner result sets with less noise.

Stats, RSS Support, and Indexer Response Times

NZBHydra2 logs detailed statistics on every search and download. The stats dashboard shows indexer response times, download shares per indexer, NZB age distributions, and historical query data. This is genuinely useful for identifying slow or underperforming indexers.

RSS support allows NZBHydra2 to expose a configurable RSS feed for each configured indexer. Cache times are adjustable, which helps avoid hammering API rate limits. Automation tools can poll these feeds for new releases without sending a live search query every time.

NZBHydra2 Cons for Beginners

The developer’s own documentation notes that if most of the feature list is unfamiliar, the tool may not be the right starting point. That is honest and worth taking seriously.

Key friction points for new users:

• Configuration depth can be overwhelming; dozens of settings exist that most users will never touch
• API key management requires you to obtain and enter keys for each indexer manually
• No built-in download engine; it relies entirely on SABnzbd, NZBGet, or another client
• Extensive configurability means there is rarely one obvious correct setting

Starting with only two or three indexers and default settings reduces the learning curve significantly.

Installing NZBHydra2 With Docker

Docker is the most reliable and repeatable way to run NZBHydra2, especially on Linux-based home servers and NAS devices. The official images from LinuxServer.io and hotio both work well, and both are actively maintained. The setup process involves pulling an image, mapping ports and volumes, and passing a few environment variables before the web interface becomes accessible.

What You Need Before the Setup Process

Before pulling any Docker image, confirm the following:

• Docker is installed and the daemon is running
• A config directory exists on the host for persistent storage (e.g., /home/user/nzbhydra2/config)
• Port 5076 is available on the host (NZBHydra2’s default port)
• Your PUID and PGID are known (run id in a terminal to check)
• Your timezone string is ready (e.g., America/New_York)

The lscr.io/linuxserver/nzbhydra2 image handles permissions using PUID, PGID, and UMASK environment variables, which prevents common file ownership problems when the container writes to host directories.

Docker Run Example and Key Parameters

A basic docker run command to get NZBHydra2 running looks like this:

docker run -d 
  --name=nzbhydra2 
  -e PUID=1000 
  -e PGID=1000 
  -e UMASK=002 
  -e TZ=America/New_York 
  -p 5076:5076 
  -v /path/to/config:/config 
  --restart unless-stopped 
  lscr.io/linuxserver/nzbhydra2:latest

Key parameters explained:

After the container starts, the interface is accessible at http://127.0.0.1:5076.

Docker Compose Example With Persistent Storage

For a more maintainable setup, Docker Compose is the better approach. Create a docker-compose.yml file with the following structure:

services:
  nzbhydra2:
    image: lscr.io/linuxserver/nzbhydra2:latest
    container_name: nzbhydra2
    hostname: nzbhydra2
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - TZ=America/New_York
    volumes:
      - /path/to/config:/config
    ports:
      - 5076:5076
    restart: unless-stopped

Run docker compose up -d from the directory containing the file. The hostname field is optional but useful when referencing the container from other services on the same Docker network. The /config volume mount is where NZBHydra2 stores its database, settings file, and logs, so this path should point to a reliable location on the host with adequate storage.

Connecting Indexers and Downloaders

Once the container is running and the web interface loads, the next step is wiring in your indexers and download clients. NZBHydra2 acts as the middle layer, so both sides need to be configured before any search-to-download flow works end to end.

Adding Newznab Sources and API Credentials

Navigate to Config > Indexers in the NZBHydra2 web interface and click Add indexer. For newznab-compatible indexers, you will need:

• The indexer’s API URL (usually listed in your account settings on the indexer site)
• Your API key for that indexer

Paste both into the appropriate fields and save. NZBHydra2 will test the connection automatically. Raw sources like Binsearch and NZBIndex do not require an API key and can be enabled with a checkbox. It is worth enabling them as supplementary sources even if your primary indexers are newznab-based, since they expand coverage for older binary content.

Connecting SABnzbd and NZBGet

Go to Config > Downloaders and add your download client. For SABnzbd:

• Set the host (e.g., http://localhost:8080)
• Enter your SABnzbd API key (found under SABnzbd’s Config > General)
• Select the default category if you use category-based folder routing

For NZBGet, the process is similar. Enter the host, port, and NZBGet username and password. Once saved, NZBHydra2 can push NZB files directly to the downloader from the search results interface with a single click.

Testing Search and NZB Download Flow

Run a test search from the NZBHydra2 interface. Verify that results appear from multiple indexers and that the source column shows different indexer names. Then select a result and send it to SABnzbd or NZBGet using the download button.

Check your download client to confirm the NZB arrived and is queued. If it fails, the most common causes are a mistyped API key, a host address that uses localhost when Docker networking requires the host IP instead, or a firewall blocking the port.

Automation Integrations and Search Workflows

NZBHydra2 functions as a single API synchronization hub that automation tools like Sonarr, Radarr, and others treat as one unified indexer. Rather than configuring each app with five separate indexer entries, each app points to NZBHydra2 and inherits all configured sources automatically. Media ID support and query generation make the integration work cleanly across different app types.

Using NZBHydra2 as an Indexer Source for Sonarr and Radarr

In Sonarr, go to Settings > Indexers and add a new Newznab indexer. Point the URL at your NZBHydra2 instance:

http://[your-host]:5076/api

Copy the NZBHydra2 API key from Config > Main and paste it into Sonarr’s indexer API key field. Radarr follows the identical process. Once connected, every search Sonarr or Radarr runs flows through NZBHydra2, which queries all your configured indexers and returns merged results.

This approach is cleaner than adding each indexer individually to Sonarr and Radarr. One connection point means one place to update API keys, one place to check stats, and one place to adjust filtering rules.

Other App Integrations for Lidarr, Mylar, and CouchPotato

Lidarr, Mylar, LL, and CouchPotato all connect to NZBHydra2 using the same newznab endpoint format. The configuration steps are nearly identical to Sonarr and Radarr: add a newznab indexer, enter the NZBHydra2 URL and API key, and save.

NZBHydra2 also supports nzb360, a mobile app for managing Usenet and home server automation from Android. Point nzb360 at the NZBHydra2 URL with the API key and it will display search results and allow NZB downloads directly from your phone.

Media ID Lookup and Search Logic

NZBHydra2 supports all major media identifier formats used by automation tools like Sonarr and Radarr. When an automation tool sends a search request using only a media ID, NZBHydra2 handles ID conversion and query generation automatically.

If an indexer does not support the specific ID type provided, NZBHydra2 converts it to a text query instead. If a search returns zero results, it falls back to a generated query based on the title. This logic makes the automation stack more resilient when individual indexers have inconsistent metadata support.

Privacy, Troubleshooting, and Tool Alternatives

Running NZBHydra2 self-hosted gives you meaningful control over where your search queries go, but it does not automatically make those queries private. A few targeted configuration steps close the most common exposure points. Knowing the typical setup problems in advance also cuts troubleshooting time significantly.

Common Setup Problems With Ports, Permissions, and API Access

The three most frequent issues when starting out:

Port conflicts. If port 5076 is already in use on the host, the container will fail to bind. Change the host-side port mapping (e.g., -p 5077:5076) and update any firewall rules accordingly.

Permission errors on the config volume. If PUID and PGID do not match the owner of the host config directory, NZBHydra2 will fail to write its database. Run id in the terminal and match the values exactly.

API key mismatches. When NZBHydra2 cannot reach an indexer or a downloader rejects pushes, verify that the API key was copied without trailing spaces and that the host address is reachable from inside the container. Docker networking sometimes requires using the host’s LAN IP rather than localhost.

Privacy Basics With SSL, VPN, and Proxy Options

NZBHydra2 itself does not encrypt traffic between your browser and the interface by default. For remote access, place it behind a reverse proxy with SSL termination.

For the connection between NZBHydra2 and your indexers, a VPN at the host or container level keeps your Usenet search queries off your ISP’s traffic logs. NZBHydra2 also supports proxy configuration natively, which lets you route outbound indexer requests through a SOCKS5 or HTTP proxy without routing all other traffic through it.

Authentication is configurable under Config > Auth, and enabling it is worth doing even on a local network. It prevents other devices on your network from accessing search history or pushing NZB downloads.

NZBHydra2 vs Prowlarr and Jackett for Beginners

These three tools are frequently compared but serve somewhat different roles:

Prowlarr handles indexer synchronization with Sonarr and Radarr more tightly but offers weaker manual search capabilities. NZBHydra2 excels at manual browsing, stats, and fine-grained filtering. Many users run both: Prowlarr for Arr-side indexer management and NZBHydra2 for manual Usenet search. For a deeper technical comparison of the two, see our NZBHydra2 vs Prowlarr breakdown.

Jackett’s primary value is exposing trackers as Torznab sources. If your workflow is Usenet-centric, Jackett is less relevant unless you want to pull in tracker results alongside your NZB indexers.

All three are available on GitHub and maintained as active open source projects.

Frequently Asked Questions

How do I install and run it using Docker?

Pull the lscr.io/linuxserver/nzbhydra2:latest image and run it with PUID, PGID, TZ, a port mapping of 5076:5076, and a volume mapping for /config. After the container starts, the web interface is accessible at http://127.0.0.1:5076. The LinuxServer.io image is the most commonly used and includes automatic update support.

How do I set it up with docker-compose?

Create a docker-compose.yml file that defines the lscr.io/linuxserver/nzbhydra2:latest image, sets the environment variables for PUID, PGID, UMASK, and TZ, maps port 5076:5076, and mounts a host directory to /config for persistent storage. Run docker compose up -d to start the container in the background. Configuration data and the database will persist in the mapped config directory between container restarts.

What port does it use by default, and how can I change it?

NZBHydra2 defaults to port 5076. To change it in Docker, modify the host-side port in the mapping (e.g., -p 5080:5076 to expose it on port 5080 instead). You can also change the internal port through the NZBHydra2 web interface under Config > Main, though adjusting only the host-side Docker mapping is simpler for most setups.

How do I configure indexers and connect it to Sonarr and Radarr?

Add indexers under Config > Indexers by entering each indexer’s API URL and API key. In Sonarr or Radarr, add a new Newznab indexer pointing to http://[host]:5076/api and enter the NZBHydra2 API key from Config > Main. All searches from Sonarr and Radarr will then route through NZBHydra2 and query all configured indexers simultaneously.

How does it compare to Prowlarr for managing NZB indexers?

Prowlarr integrates more tightly with the Arr suite and syncs indexers directly to each app, while NZBHydra2 provides richer manual search, stats dashboards, and more granular filtering controls. For Usenet-primary setups with a need for detailed indexer performance data, NZBHydra2 is the stronger choice. Some users run both tools in parallel for different parts of their workflow.

How can I access and use it from an Android device?

The nzb360 app supports NZBHydra2 natively. Add NZBHydra2 as a connection in nzb360 using your host’s IP or domain, port 5076, and the API key from Config > Main. This gives you access to search and NZB download controls from your phone without needing to open a browser.

To get the most out of NZBHydra2, you need a reliable Usenet provider with strong retention and fast download speeds backing your indexers. A provider like Newshosting or Easynews gives you the completion rates and binary retention that make meta search worthwhile. Get Newshosting or Get Easynews to pair your NZBHydra2 setup with a provider that can deliver on the searches it surfaces.