在家庭 NAS 上自动化追剧，通常意味着要同时维护 Sonarr、Radarr、Lidarr、Prowlarr、Bazarr 和 Overseerr 六个独立的 Docker 容器。个人开发者 CoderLuii 近期开源了基于 Go 语言编写的 HolyArrs，试图用一个默认运行在 6262 端口的单体容器把这六款工具全部替换掉。根据 2026 年 11 月 8 日测算的 amd64 架构数据，这六个传统应用的镜像下载体积总和为 718.2 MB，而 HolyArrs 仅有 14.9 MB，体积缩小了约 48 倍；在管理 10,000 个条目（含 55,000 部电影和剧集）时，空闲内存占用约为 140 MiB。
单看账面数字，这是一次极具诱惑力的工程瘦身。但拆开其底层架构与迁移文档就会发现，HolyArrs 并不是靠某种魔法把六套系统无损塞进了 15 MB，而是通过砍掉重度玩家依赖的高阶筛选规则、延后部分核心功能，并把元数据请求集中到开发者个人自费的服务器上，换来了表面的开箱即用。
缩水 48 倍的秘密与残缺的六合一
传统 *arr 家族大多基于 .NET 或 Node.js 构建，每个容器都打包了各自的运行时与数据库，六个容器并跑天然带有冗余开销。HolyArrs 改用编译型的 Go 语言重写，确实吃到了语言层面的轻量化红利，但它能压到 14.9 MB，更直接的原因是许多功能尚未兑现或被直接舍弃。
开发者在今年 10 月的早期社区宣传中，曾声称该应用能一并替代 qBittorrent 和 SABnzbd 等下载器；但在当前版本的官方文档中，这一口径已明显收缩。现阶段的 HolyArrs 既不能自己下载文件，也不具备流媒体转码与播放能力，用户依然必须在外部额外部署 qBittorrent 等下载客户端，以及 Plex、Jellyfin 或 Emby 等媒体服务器。
即便是它明确宣称替代的那六个组件，目前也存在明显短板：
| 传统组件 | 原镜像体积 | HolyArrs 现阶段实际替代程度 |
|---|---|---|
| Overseerr / Prowlarr | 261.6 MB (合计) | 完整包含流媒体式探索界面、求片审批与索引源管理 |
| Sonarr / Radarr | 178.9 MB (合计) | 仅支持基础预设抓取，丢弃自定义格式与历史记录 |
| Bazarr (字幕管理) | 156.4 MB | 仅保留本地伴随字幕，在线字幕搜寻延后至 1.0 版本之后 |
| Lidarr (音乐管理) | 121.3 MB | 探索界面中的音乐模块仍在建设中 |
对于冲着“一个容器搞定影音室”的新手来说，现在部署 HolyArrs 意味着在线自动匹配字幕和完整的音乐探索暂时缺位。截至 2026 年 11 月 10 日，开发者在分享借助 Claude Code 将整个应用装进 15 MB 的开发历程时，也明确将当前版本定性为 Beta 测试版，建议用户暂勿将其作为主力生产环境。
高阶玩家无法迁移的硬伤
HolyArrs 提供了从旧组件一键读取配置的无损迁移向导，允许新旧容器并排运行测试。这套设计很体贴家庭轻度用户，但对于混迹 PT 站与 Usenet、习惯了精细化洗版的硬核玩家来说，迁移代价过于高昂。
根据官方迁移文档，当用户将 Sonarr 和 Radarr 的配置导入 HolyArrs 时，原有的质量配置文件只能近似映射为最接近的内置预设规则（Pick rules）。高阶玩家耗费大量精力调校的自定义格式（Custom formats）、发布词规则、语言配置、自动标签规则以及抓取历史记录，在迁移过程中会被全部丢弃。
砍掉复杂规则引擎换来的极简，本质上是把筛选权从用户手里收走。
更关键的限制在于周边生态的断裂。自托管影音圈广泛依赖 TRaSH Guides 规则库，并通过 Recyclarr、Maintainerr 和 Cleanuparr 等外部自动化工具定期同步评分策略、清理过期媒体。HolyArrs 的旧应用兼容 API 明确不支持这三款高阶工具；同时，外部客户端通过兼容接口访问时，只能看到影视条目的主副本，额外的 4K 版本对外部完全不可见。
加上仓库主分支目前仅显示 10 次提交，借助 AI 编程工具快速拉起的工程底座仍在暴露边界漏洞。例如 2026 年 11 月 10 日登记的 Issue #165 显示，许多同时维护“1080p 实例”与“4K 实例”的双实例玩家在迁移时发现，向导里添加第二个 Sonarr 实例会直接覆盖掉第一个实例，必须分批导入才能规避。
免配 API 密钥背后的中心化软肋
HolyArrs 在宣传中把“无需四处寻找和复制 API 密钥”列为核心卖点。不仅内部组件打通免去了跨容器粘贴密钥的繁琐，连获取剧集信息、海报和榜单也无需用户自己去申请第三方元数据密钥。
但对于讲究数据自主权的自托管（Self-hosted）社区而言，这种零门槛设计恰恰埋下了一颗定时炸弹。
HolyArrs 之所以能省去用户的配置步骤，是因为每一个部署在本地 NAS 上的实例，都必须连接由开发者个人按月自掏腰包维护的中心化元数据服务器。开发者在文档末尾坦言，虽然软件免费开源（采用 GNU AGPL-3.0 协议），但运行并不免费，目前全靠社区赞助来维持这台元数据服务器的月度账单。
- 风险.一旦该开源项目因热度飙升导致服务器带宽账单击穿个人承受能力，或者开发者未来精力转移停止续费，全球所有依赖该服务的本地 HolyArrs 容器都会瞬间失去剧集检索、海报加载与榜单更新能力。
对于厌倦了为了看一部剧去排查六个容器日志的轻度 NAS 用户，HolyArrs 确实撕开了一道降低门槛的口子，拉起一个容器试玩完全不亏；但对于追求规则掌控力与系统长期自治的玩家，在 1.0 版本兑现在线字幕、补齐高阶规则兼容，尤其是允许用户回退到自定义元数据 API 密钥之前，Sonarr 和 Radarr 依然无可替代。