HolyArrs 将六款媒体管理应用整合至单个 15 MB 的软件包中

HolyArrs 用一个仅需 14.9 MB 磁盘空间的自托管工具取代了一套包含 Sonarr、Radarr、Lidarr、Bazarr、Prowlarr 和 Seerr 在内的六款独立媒体管理应用程序。通过整合这些功能，开发者旨在消除对多个登录、端口和 API 密钥的需求，为管理自有媒体库的用户提供统一的体验。

此视觉效果支持了管理电影、剧集和音乐的统一界面描述。

整合 'Arr' 技术栈

典型的自托管媒体服务器设置通常需要运行六个不同的应用程序来处理内容获取和组织的各个方面。这些包括用于电视和电影的 Sonarr 和 Radarr，用于音乐的 Lidarr，用于字幕的 Bazarr，用于索引器管理的 Prowlarr，以及用于处理请求的 Seerr 或 Overseerr。

此图表由 HN Digest 根据 github.com 报告的数据绘制；数值与源文件一致。

HolyArrs 将这些工作流统一到一个界面中。它允许用户像流媒体服务一样浏览内容、请求标题，并在单个登录和端口内管理“挑选规则”（Pick rules）——这些规则决定了基于大小、质量或语言的哪个版本胜出。

这张图片展示了整合部分描述的统一浏览体验。

技术效率与资源节省

HolyArrs 主要的技术优势在于其更小的占用空间。开发者报告称，它所取代的六个应用程序合并下载大小为 718.2 MB，而 HolyArrs 的下载大小约为 15 MB。

在内存使用方面，HolyArrs 在管理包含 10,000 个标题和 55,000 个电影/剧集的库时，保持约 140 MiB 的闲置 RAM。这与各个独立应用程序的内存需求形成了鲜明对比，后者的内存需求每个可能在 80 MB 到 180 MB 以上不等。

迁移与兼容性

为了降低切换门槛，HolyArrs 包含了一个迁移工具。它可以读取现有 Sonarr、Radarr 和 Lidarr 实例中的数据，以导入库文件夹、质量配置文件和索引器。它还支持导入 Prowlarr 索引器和 Bazarr 字幕偏好。

该应用程序作为协调器而非独立的下载器运行；它连接到现有的客户端，如 qBittorrent、Transmission、Deluge 和 SABnzbd。它还提供与 Plex、Jellyfin 和 Emby 等主流媒体服务器的原生兼容性。

当前限制与路线图

虽然 HolyArrs 简化了管理堆栈，但在 1.0 版本中它具有特定的功能边界。它目前不具备内置下载器，这意味着用户仍需维护外部客户端来进行实际的文件获取。

此外，该项目尚未包含 AI 功能、MCP（模型上下文协议）支持或原生的手机和电视应用程序。‘探索’浏览界面中的音乐支持目前也正在开发中。