Huntarr is gone: what to run instead

Huntarr is gone: what to do first

Huntarr is gone, and for most people the safe thing to run instead is the search that Sonarr and Radarr already ship. If Huntarr is still running on your server, stop it today. Then rotate the API key of every app it was connected to. This guide shows both steps, then covers what to run in its place.

Huntarr ran paced searches for missing and cutoff-unmet items across Sonarr, Radarr and the other arr apps. On 24 February 2026, a public security review of version 9.4.2 reported that an unauthenticated settings endpoint returned a full configuration dump. That dump held the API keys and passwords of every connected Sonarr, Radarr, Prowlarr, Lidarr, Readarr and Whisparr instance. The developer then deleted the GitHub repository, the Discord server and the subreddit. As of 1 October 2026 the repository returns 404, so no fixed release is coming.

An API (application programming interface) key in an arr app is not a limited token. It gives full control of that app. The Servarr wiki says the key "if given to the wrong person with access could do all kinds of things to your library". Anyone who holds it can delete media and change every setting, including where downloads go. So a leaked key stays dangerous after Huntarr is switched off. Only a new key fixes it.

Step 1: stop Huntarr and remove it from the stack

First, find the container and look at how its port was published.

docker ps -a --filter name=huntarr

Read the PORTS column. An entry that starts with 0.0.0.0: means Docker published the port on every network interface. Docker writes its own firewall rules for published ports, so ufw does not block them. Why Docker published ports bypass ufw explains the mechanism. If you see 0.0.0.0 here, assume anyone who could reach that port could read your keys.

Stop the service, delete its block from the compose file, then let Compose remove the leftover container. Your service may have a different name. docker compose config --services lists the real names.

cd ~/arr-stack
docker compose stop huntarr
nano docker-compose.yml
docker compose up -d --remove-orphans
docker ps -a --filter name=huntarr

In the editor, delete the whole huntarr: service block and save. --remove-orphans removes containers whose service no longer exists in the file. The last command should now print only the header line. Any row under it means a container with that name still exists.

Huntarr's config directory still holds the old keys in plain text. They stop working after Step 2, but there is no reason to keep them. Take the host path from the volumes: line of the block you deleted. The path below is an example. Look before you delete:

ls -la ./huntarr
sudo rm -rf ./huntarr
docker images | grep -i huntarr

If the last command prints an image, remove it with docker image rm followed by the IMAGE ID it shows.

Step 2: regenerate the API key in every connected app

Do this in every app Huntarr was connected to. Include Prowlarr. In each app, open Settings, then General, then find the Security section. Before you change anything, copy the current key into a scratch file. You need it for the check below. Then click the reset icon at the end of the API Key field and confirm.

Now prove the old key is dead. Send a request with the old key. The app should refuse it.

OLD=paste-the-old-key-here
curl -s -o /dev/null -w '%{http_code}\n' -H "X-Api-Key: $OLD" http://127.0.0.1:8989/api/v3/system/status

401 means the old key is rejected, which is what you want. 200 means the app still accepts the old key, so the reset did not save. Port 8989 is Sonarr. Use port 7878 with /api/v3/ for Radarr, and port 9696 with /api/v1/ for Prowlarr. Lidarr (8686) and Readarr (8787) also use /api/v1/. If you changed any ports, the arr stack ports reference lists the defaults so you can map yours.

This check needs the app's port published on the host. If curl prints 000 and nothing else, nothing answered on that address. Run the same command inside the container instead, or publish the port on 127.0.0.1 only.

The dump also held passwords. If an app used a login password, change it in the same Security section. If you used that password anywhere else, change it there too. If you lock yourself out on the way, resetting a Sonarr or Radarr login password covers the recovery.

Step 3: update every client that used the old keys

A new key breaks every client that still sends the old one. That is the goal, but you must fix the clients you actually use. The fastest way to find them is to search your app data for the old key:

sudo grep -rl "$OLD" /path/to/appdata

Each file it prints belongs to a client that still needs the new key. Some matches will be database files. Treat those as a pointer to which app to fix in its web interface. Do not edit the database by hand.

The usual places:

• Prowlarr app connections. In Prowlarr, open Settings, then Apps. Edit each Sonarr and Radarr entry, paste that app's new key, click Test, then Save.
• Prowlarr's own key. If you rotated Prowlarr's key, the indexers it pushed into Sonarr and Radarr still carry the old one. Click Sync App Indexers on the Apps page, and Prowlarr rewrites them with the new key.
• Download clients. Most download clients never hold an arr key. A post-processing script or a webhook that calls back into Sonarr or Radarr does hold one, and the grep above finds it.
• Request tools and dashboards. Anything that shows your library or sends requests to Sonarr and Radarr stores their keys. Update each one and run its connection test.

Connecting Prowlarr, Sonarr, Radarr and a download client walks through each of those screens. When you finish, open System, then Status, in each arr app. A health warning about indexers or a failed connection usually means one client still sends the old key.

What replaces Huntarr: the built-in Wanted searches

To pick a replacement, first see the gap Huntarr filled. Sonarr and Radarr find releases in two ways. RSS sync reads the newest entries of each indexer's feed on a timer. It is good at grabbing new releases. But an episode that aired before you added the series is no longer in any feed, so RSS sync never sees it. Only a search finds old items. The apps do not run those searches on a timer by themselves, and that was the job Huntarr did.

The apps give you the same searches by hand, under Wanted:

• Wanted, then Missing. Monitored items that have no file on disk yet.
• Wanted, then Cutoff Unmet. Items that have a file, but below the quality cutoff of their profile.

Both pages have Search Selected and Search All buttons. Search All shows a confirmation with the number of items it will search. Read that number. The Servarr wiki warns: "This search process cannot be canceled once started without restarting Sonarr or disabling all of your indexers." On a large library, start with Search Selected on one page, and watch how your indexers respond.

Keep RSS sync running alongside. It lives in Settings, then Indexers, as RSS Sync Interval. The wiki gives the range as 10 to 120 minutes. Setting it to 0 disables it, which stops all automatic release grabbing. Leave it on.

Also use the search option on the Add dialog when you add a new series or movie. One search at add time covers the backlog for that item, so it never lands in Missing.

How to run the Wanted searches on a schedule

If you want Huntarr's unattended behaviour, a cron job can call the same commands through the API. Sonarr names them MissingEpisodeSearch and CutoffUnmetEpisodeSearch. Radarr names them MissingMoviesSearch and CutoffUnmetMoviesSearch. The job holds one key per app, in a file only root can read.

Create the key file with mode 600 first, then fill it in:

sudo install -m 600 /dev/null /etc/arr-search.env
sudo nano /etc/arr-search.env

SONARR_KEY=your-new-sonarr-key
RADARR_KEY=your-new-radarr-key

Then write the script with sudo nano /usr/local/bin/arr-wanted-search:

#!/bin/sh
set -eu
. /etc/arr-search.env
curl -fsS -X POST -H "X-Api-Key: $SONARR_KEY" -H 'Content-Type: application/json' -d '{"name":"MissingEpisodeSearch"}' http://127.0.0.1:8989/api/v3/command
echo
curl -fsS -X POST -H "X-Api-Key: $RADARR_KEY" -H 'Content-Type: application/json' -d '{"name":"MissingMoviesSearch"}' http://127.0.0.1:7878/api/v3/command
echo

Make it executable for root only, and run it once by hand:

sudo chmod 700 /usr/local/bin/arr-wanted-search
sudo /usr/local/bin/arr-wanted-search

Each curl line should print a JSON object that describes the queued command. The search then shows as a task under System, then Tasks, in each app. curl: (22) The requested URL returned error: 401 means the key in the env file is wrong or still the old one. curl: (7) Failed to connect means the port is not published on the host. Publish it on loopback only, for example 127.0.0.1:8989:8989.

Schedule it once a week, at night:

echo '30 3 * * 0 root /usr/local/bin/arr-wanted-search' | sudo tee /etc/cron.d/arr-wanted-search

For quality upgrades, copy the script, swap in the two cutoff command names, and run that copy monthly. These commands search every matching item in one run. Huntarr searched in small batches. On a big library a full run sends many queries at once, and an indexer with a daily limit will start refusing them. Prowlarr can cap this for you: edit the indexer, show advanced settings, and set a Query Limit.

Newtarr: the ElfHosted fork, and where it belongs

On 24 February 2026, ElfHosted announced Newtarr, a fork of an older Huntarr release. As of October 2026 its README names that release as v6.6.3. Treat it as what it is: a third-party fork with its own maintainers, which holds every arr key you give it. The README says authentication is disabled by default, because the project is designed to run behind a single sign-on proxy. So the port must never be reachable from the internet.

If you run it, start from the compose example in the project's README and take the image name from there. Make one change before you start it: bind the port to 127.0.0.1, so only the server itself can reach it. The ports: lines of the service should look like this:

    ports:
      - "127.0.0.1:9705:9705"

After docker compose up -d newtarr, check the binding with sudo ss -tlnp | grep 9705. You should see 127.0.0.1:9705. A line with 0.0.0.0:9705 means the port is public, so fix the compose file before you enter any keys. To open the interface from your laptop, use an SSH tunnel: ssh -L 9705:127.0.0.1:9705 you@your-vps, then browse to http://localhost:9705. For browser access without a tunnel, put it behind forward authentication, as in protecting self-hosted apps with OAuth2 Proxy. Connect only the apps you actually want searched, because each connection adds one more key to its config file.

Why a tool that holds every arr key is a master key

The Huntarr problem is not specific to Huntarr. Any companion tool that holds the API key of every arr app is a master key: one leak opens every app at once. Dashboards, request tools and search helpers all fit this pattern. Each new one adds a place where all your keys sit together.

Three habits keep that risk small. First, never publish a companion tool's port on 0.0.0.0. Bind it to 127.0.0.1, or put it on a private network. A mesh VPN works well for that, and what a Tailscale control plane can and cannot see explains the trade. Second, put anything you open in a browser behind forward authentication, not behind the tool's own login screen alone. Third, keep authentication on in the arr apps themselves. When it is safe to disable Sonarr and Radarr authentication covers the narrow cases where turning it off is reasonable.

If you are building the stack fresh, the Docker Compose arr stack guide sets this up from the start. To audit what you run today, list every container port that is open on all interfaces:

docker ps | grep '0.0.0.0'

Each line it prints is reachable from the internet, unless your provider's network firewall blocks it. For each one, decide whether it really needs to be public.

FAQ

Is it safe to keep running Huntarr on a private network?

No. The project is deleted, so the reported flaw will never be fixed in Huntarr itself. On a private network, any device or container that can reach the port can still request the configuration dump and read every arr key. Remove the container, delete its config directory, and rotate the keys of every connected app.

Do I need to rotate my API keys if Huntarr was never exposed to the internet?

Yes. You cannot easily prove who reached the port, and a single rotation costs a few minutes per app. After the reset, a request with the old key should return 401. That gives you a clear test that the leaked key no longer works.

Does regenerating the Sonarr API key break Prowlarr?

Yes, until you update it. Prowlarr stores each app's key under Settings, then Apps. Paste the new Sonarr key into the Sonarr entry, click Test, then Save. If you also reset Prowlarr's own key, click Sync App Indexers so Sonarr and Radarr receive it.

Is Newtarr safe to use instead of Huntarr?

Newtarr is a third-party fork of an older Huntarr release, maintained by ElfHosted. Its README says authentication is off by default, because it expects a single sign-on proxy in front of it. Bind its port to 127.0.0.1 and reach it over an SSH tunnel, a private network, or forward authentication. Never publish it to the internet.

How do I make Sonarr search for missing episodes automatically?

Sonarr does not search its backlog on a timer by itself. RSS sync only catches new releases. Use Wanted, then Missing, then Search All by hand. Or schedule a cron job that posts {"name":"MissingEpisodeSearch"} to /api/v3/command with your API key, once a week, and set a Query Limit on each indexer in Prowlarr so the run stays within your indexer limits.