HolyArrs: One Media App, One Big Outside Dependency

HolyArrs wants to collapse the usual home-media stack into one self-hosted app. Instead of separate tools for movies, TV, music, subtitles, requests, indexers and download clients, it offers one login, one port and one web UI. The pitch is appealing if you have ever opened three different *arr apps to find out why one episode did not land.

The current release is HolyArrs 1.0.19, published on November 11, 2026. It is free, open source under AGPL-3.0, and distributed mainly as a Docker image. This release adds rTorrent and ruTorrent support and fixes several Usenet and download-accounting problems.

Before the useful part, one design choice needs to be upfront: HolyArrs is self-hosted, but it is not self-contained. On first start, every install registers with api.holyarrs.com, the metadata server run by the project. The startup log recorded that registration even in safe mode, before creating an owner account or adding a folder.

What the metadata server does

HolyArrs uses that server for title, show and music lookups, charts, trailers, ratings, Wikipedia details, anime episode maps and artwork. It is why setup can say "no API keys needed". Your install sends an install token, lookup words or IDs, display language and region, normal request headers, and your public IP as part of the web request. The docs say files, folder paths, library contents, downloads, history, users, passwords and downloader keys are not sent. A country install count can be turned off.

The dependency cannot simply be switched off. According to the project's own documentation, searches and new details stop without the metadata server, while your existing Library and downloads keep working. Setting your own TMDB key moves some movie and show lookups directly to TMDB, but the install still registers with HolyArrs. Pointing HOLYARRS_METADATA_URL elsewhere moves the dependency; it does not remove it.

That does not make HolyArrs dishonest. The documentation is unusually clear about what leaves the machine: the docs say your media and accounts stay on your server, while discovery depends on an outside service the author pays for. If you want a media stack that keeps working fully offline or inside a sealed network, this is not that stack.

What we tried

We did not test the recommended Docker install because Docker is not available in our test environment. We did not connect Plex, Jellyfin, Emby, an indexer, a torrent client, a Usenet client or a media folder. Nothing in this article proves the full request-to-download flow.

What we could test was narrower. We built HolyArrs 1.0.19 from source on Linux, started the binary with a fresh temporary config in safe mode, and opened the first-run page locally. The app created its local config, database, master key and initial backup, then showed a "Set up HolyArrs" screen with password, Plex, Jellyfin and Emby owner choices. Safe mode kept sign-in, Library, settings, backups and health available, while searches, downloads, imports, subtitles and schedules were off.

Even in that limited start, the log recorded a metadata-server registration. We did not capture packets or independently validate every field sent; the data list above comes from the project's documentation. That is why the dependency belongs near the top of any review, not in a footnote.

What HolyArrs is trying to replace

The project positions itself against the familiar set of Sonarr, Radarr, Lidarr, Prowlarr, Bazarr and Seerr. It handles requests, Source rules, download clients, library organization and media-server notification from one place. The docs list qBittorrent, Transmission, Deluge, rTorrent, SABnzbd and NZBGet as downloaders; Plex, Jellyfin and Emby as media servers; and Torznab, Newznab, Prowlarr or Jackett as sources.

The boundary matters: HolyArrs does not download anything itself. It searches your Sources and sends the chosen release to a download client that is already running. qBittorrent, SABnzbd or another listed client does the actual downloading.

There are sensible security warnings too. A new install has no default password, and whoever opens it first becomes the owner. The docs tell you to create that account immediately and not to forward port 6262 to the internet; use a VPN or an HTTPS reverse proxy instead. HTTPS protects the connection, but it does not replace account and access control.

Verdict

HolyArrs is worth watching if your problem is app sprawl and you are comfortable with a central metadata service. The source is available, the Docker path is documented, and the privacy documentation is specific. The GitHub repository was created on November 9, 2026, and the 1.0.19 release followed on November 11. That is active, but too new to call a track record.

But treat this as a qualified first look, not a tested replacement for your existing stack. We verified the source build and first-run behavior only. The recommended Docker install and every real media, indexer and downloader workflow remain untested here. Most of all, do not read "self-hosted" as "no outside service". HolyArrs is documented as keeping your library local, but its discovery brain still phones home by design.

Image credit: source view from the AGPL-3.0 HolyArrs repository, showing the default metadata server constant.