出来事の日付：2026年11月10日。

HolyArrsという新たなオープンソースプロジェクトが、テレビ番組、映画、音楽、字幕、インデクサー、リクエストを管理する複数のツールを個別に動かす代わりに、一つのセルフホスト型アプリケーションを利用する構成を提案している。開発者によると、ダウンロードするイメージは約15 MBで、大規模なカタログを持つ状態でも、アイドル時のメモリ使用量はおよそ140 MBだという。

HolyArrsでは、利用者がライブラリー形式の画面を閲覧し、作品をリクエストできる。アプリケーションは設定済みの取得元を検索し、利用者が定めたルールに従ってリリースを選び、既存のダウンローダーへ処理を送り、取得が完了したメディアをライブラリー内に整理する。接続されたメディアサーバーは、追加された項目を検出する。このプロジェクトにはまだ独自のダウンローダーが含まれていないため、利用者は引き続きqBittorrentやSABnzbdなどのソフトウェアを用意する必要がある。

同プロジェクトが比較対象とするのは、現在Sonarr、Radarr、Lidarr、Bazarr、Prowlarr、Seerrを組み合わせて使っている家庭だ。HolyArrsは、これら6つのアプリケーションが担う連携・管理の層を、一つのログイン、ポート、設定画面に置き換える。開発者によれば、比較に用いた6つのコンテナーイメージは合計718.2 MBで、HolyArrsのダウンロードサイズはその約48分の1になる。これらの測定値とメモリ使用量はプロジェクト自身によるもので、提供された資料には独立したベンチマーク検証は含まれていない。

インストールにはDocker Composeファイルを使い、amd64、arm64、armv7の各システムに対応する。ポート6262を開いた後、最初のアクセス者が所有者アカウントを作成し、ライブラリーフォルダー、ダウンローダー、コンテンツ取得元を設定する手順を完了する。ドキュメントは、既定のパスワードがなく、未登録のインスタンスを最初に開いた人が所有者になるため、管理者に対して直ちにアカウントを作成するよう注意を促している。

移行ツールは、既存のアプリケーションやバックアップアーカイブから設定を読み込める。利用者は取り込む内容を選び、動作をテストした上で移行を実行する。HolyArrsによれば、従来のアプリケーションは変更しないため、両方の構成を並行して稼働させることができる。メディアファイルは元の場所に残る一方、パスワードやキーは再入力するか、別途取り込む必要がある。カスタムフォーマット、タグ、履歴は移行されない。

ドキュメントは運用上の注意点も挙げている。設定ディレクトリー内のキーファイルは保存された認証情報の復号に必要だが、通常のバックアップには含まれないため、管理者は別途保管しなければならない。コンテナーイメージには対話型シェルが含まれない。HolyArrsは独自の診断コマンドを提供し、アップグレード時に保存形式を変更する前にはバックアップを作成する。

HolyArrsのライセンスはAGPL-3.0で、クローズドな製品向けには商用ライセンスも提供される。開発者によると、すべてのインストール環境がプロジェクトの費用で運営されるメタデータサーバーに接続するため、セルフホスト型ではあっても、外部インフラから完全に独立しているわけではない。導入を検討する利用者にとって、主な利点と引き換えに検討すべき点は統合にある。設定や障害対応が必要なサービスを減らせる一方、まだ若いプロジェクトを採用することになり、内蔵ダウンローダーは今後の計画に残され、リソース使用量の主張も現時点では保守担当者自身によるものだ。