VPSでChaptarrを自分で運用する方法
Readarrは2025年6月27日に開発終了。後継フォークChaptarrをDocker ComposeでVPSに構築し、PUIDとPGID、メタデータ問題を解説します。
Chaptarr とは何か、Readarr ユーザーに必要な理由
Chaptarr は Readarr のフォークで、1 つのインスタンスからオーディオブックと電子書籍を管理します。新しいリリースを監視し、ダウンロードクライアントに送信してから、取得したファイルの名前を変更し、ライブラリに整理します。再生機能はないため、Audiobookshelf などのプレーヤーと組み合わせて使用します。
Readarr は 27 June 2025 に廃止されました。Servarr チームの公式告知では、プロジェクトのメタデータが利用できない状態になり、Open Library への移行を進めるコミュニティの取り組みも停滞したことが理由として説明されています。リポジトリはアーカイブされています。その結果、書籍とオーディオブックのコレクションには、保守されている管理ソフトウェアがなくなりました。Chaptarr はその役割を引き継ぎました。Sonarr や Radarr ですでに使用している構成要素(インデクサー、ダウンロードクライアント、品質プロファイル、ルートフォルダー)を維持しながら、ナレーターを考慮した整理、1 タイトルの複数エディション、M4B とチャプター分割済み MP3 のサポート、MP3 から M4B への変換といったオーディオブック向けの機能を追加しています。
この手順では、9 August 2026 時点で最新リリースだったイメージタグ chaptarr/chaptarr:0.9.925 を使用しました。11 October 2026 時点の最新リリースは 0.9.965 で、27 September 2026 に公開されています。以下の手順でテストしたのは 0.9.925 のみであるため、ファイルではこのタグを使用しています。新しいバージョンへ移行する前に、リリースノートを確認してください。Chaptarr はベータ版ソフトウェアとされています。置き換えられないライブラリを指定する前に、末尾付近にある保守のセクションを確認してください。
開始前に必要なもの
Docker と Compose plugin が動作している VPS、およびライブラリを保存するための十分なディスク容量が必要です。オーディオブックは大容量です。また、hardlink を使用できない import では、一時的にファイルが 2 つ保存されます。この点については、以下の volume セクションで説明します。まだ Docker をインストールしていない場合は、VPS に Docker をインストールして実行するから始めてください。完了したら、ここに戻ります。
現時点で Chaptarr は Docker image としてのみ提供されています。Native support は現在開発中として記載されており、experimental Windows build も予定されています。distribution package はありません。container はデフォルトで /config に SQLite としてデータベースを保存します。すでに PostgreSQL server を運用している場合は、Chaptarr__Postgres__* environment variables を使用して外部 PostgreSQL server に接続できます。1 台の box で 1 人が使用する場合は、SQLite が適しています。
Chaptarr の Compose サービス
このサービスは既存のスタックに組み込みます。リリース済みのタグを固定し、Web UI は loopback のみで公開し、ダウンロードクライアントがすでに使用しているネットワークに接続します。
services:
chaptarr:
image: chaptarr/chaptarr:0.9.925
container_name: chaptarr
environment:
- PUID=1000
- PGID=1000
- UMASK=002
- TZ=Europe/Berlin
volumes:
- ./config:/config
- /srv/media/audiobooks:/audiobooks
- /srv/media/ebooks:/ebooks
- /srv/media/downloads:/downloads
ports:
- 127.0.0.1:8789:8789
restart: unless-stopped
networks:
- arr
networks:
arr:
external: trueexternal: true の行は「このネットワークはすでに存在するため、そこに接続する」という意味です。Prowlarr と torrent クライアントが別の Compose プロジェクトにある場合に使用してください。これを指定しないと、別の Compose ファイルによって独立したネットワークが作成され、Chaptarr は名前で qbittorrent を解決できません。実際の名前は docker network ls で確認します。すでに 1 つのファイルにスタック全体が定義されている場合は、chaptarr: サービスをそのファイルに追加し、networks: ブロック全体を削除してください。全体の構成については Docker Compose で構築する完全な arr スタック、名前の規則については Compose のネットワークとサービス名の解決方法 を参照してください。
設定ディレクトリを自分で作成してから、起動します。
mkdir -p ./config
sudo chown 1000:1000 ./config
docker compose up -d
docker compose ps
docker compose logs -f chaptarrdocker compose ps の出力で、コンテナが Up と表示されることを確認します。Restarting と表示される場合は、起動に失敗して再試行中です。原因のほとんどは設定ディレクトリにあります。アプリが 8789 番ポートで待ち受けを開始すると、ログのスクロールは停止します。
PUID、PGID、Docker が root として作成するディレクトリ
Chaptarr は、PUID=99 と PGID=100 を未設定のままにすると、これらをデフォルト値として使用します。これは unRAID の値です。通常の Ubuntu VPS では、これらの値が適切なユーザーに割り当てられていないため、ログインユーザーが書き込めない所有者でファイルが作成されます。id -u と id -g で自分の値を確認し、その値をファイルに設定してください。
同じファイルを操作するすべてのコンテナで、同じ組み合わせが必要です。ダウンロードクライアントは /srv/media/downloads に書き込み、Chaptarr はファイルを /srv/media/audiobooks に移動し、プレーヤーはそこから読み取ります。ダウンロードクライアントが 1000:1000 として書き込み、Chaptarr が 99:100 として実行されると、インポートに失敗します。ファイルの所有者だけで決まるわけではありません。ファイルの作成、名前変更、削除には、そのファイルを格納するディレクトリへの書き込み権限が必要です。ユーザー 1000 が一般的な 755 モードで作成したディレクトリでは、99:100 に書き込み権限がありません。そのため、Chaptarr は書籍をライブラリに登録することも、ダウンロード先から削除することもできません。UMASK=002 を指定すると、新しいファイルがグループから書き込み可能になります。複数のコンテナで同じメディアグループを共有する場合に必要な設定です。完全な対応関係は、PUID と PGID がコンテナユーザーをホスト上のファイルに対応付ける方法にあります。
README では、特定の落とし穴について注意しています。重要なので、ここでも説明します。docker compose up を実行した時点で ./config が存在しない場合、Docker はそのディレクトリを自動的に作成し、root:root を所有者にします。その後、コンテナは UID 1000 として実行されますが、自身のデータベースに書き込めないため、終了と再起動を繰り返します。ls -ln ./config で確認してください。このコマンドは、名前ではなく数値の所有者を表示します。2 つの 0 は、root が所有していることを示します。sudo chown -R 1000:1000 ./config で修正し、コンテナを再度起動してください。
オーディオブック用と電子書籍用のボリュームを分けるとハードリンクが使えない理由
上記の構成では、プロジェクト独自の実行コマンドに合わせて、/audiobooks、/ebooks、/downloadsを別々の bind としてマウントしています。読みやすい構成ですが、実際の問題が1つあります。ハードリンクが使えなくなります。
ハードリンクは、ディスク上の同じデータに対する2つ目の名前です。追加の容量を使わず、処理も即時に完了するため、arr ファミリーではコピーよりハードリンクが推奨されます。ハードリンクは、1つのファイルシステム内でのみ機能します。コンテナ内ではこれらが3つの別々のマウントポイントになっているため、ホスト側のパスが同じディスク上にあっても、カーネルはリンクの作成を拒否します。実際に確認してください。
docker exec chaptarr sh -c 'touch /downloads/linktest && ln /downloads/linktest /audiobooks/linktest'このコマンドは、Invalid cross-device linkで終わるエラーを出して失敗します。これはカーネルがマウントポイントをまたぐリンクを拒否しているためであり、Chaptarr がファイルのコピーに切り替える正確な理由です。コピーは正しく動作しますが、処理は遅くなります。また、トレントを削除するまでオーディオブックが2つ存在する状態になります。シード中はトレントを削除しないため、この状態が続きます。その後、/srv/media/downloads/linktestを削除してください。
ハードリンクを使うには、親ディレクトリを1つマウントします。
volumes:
- ./config:/config
- /srv/media:/data次に、Chaptarr のルートフォルダーを /data/audiobooks と /data/ebooks に設定し、ダウンロードクライアントにも同じ /srv/media:/data マウントを割り当てます。これにより、両方のコンテナから同一のパスが見えるようになります。まず、ホスト側が単一のファイルシステムであることを確認してください。df -h /srv/media/downloads /srv/media/audiobooksを実行し、両方で Filesystem 列に同じ値が表示される必要があります。値が異なる場合はディスクが異なるため、どのようなマウント構成でもそれらをまたぐハードリンクは作成できません。これと名前付きストレージのトレードオフについては、メディア用の bind mount と名前付きボリュームの比較で説明しています。
Web UI に外部公開せずアクセスする
ポートの行で 127.0.0.1 を指定しているのには理由があります。ufw deny 8789 では公開済みの Docker ポートを保護できません。Docker は独自の NAT(network address translation)ルールを、ufw のルールより先にカーネルが処理するチェーンへ書き込むためです。そのため、トラフィックはルールが確認される前に転送されます。この動作は頻繁に見落とされます。詳しくは 公開した Docker ポートが ufw のルールを無視する理由 を参照してください。loopback にバインドすれば、この問題を完全に回避できます。
自分のマシンから SSH トンネル経由で UI にアクセスします。
ssh -N -L 8789:127.0.0.1:8789 you@your-serverこの状態で実行したままにし、ブラウザーで http://127.0.0.1:8789 を開きます。初回起動時に認証を設定してください。その後で初めて、前段に TLS(transport layer security)対応のリバースプロキシを置くことを検討します。このようなツールを 3 つまたは 4 つ運用し、それぞれに別のパスワードを設定して SSH トンネルでアクセスするようになると、より整理された方法は、プロキシの背後に Authentik などの自己ホスト型シングルサインオンサーバーを置くことです。1 回のログインですべてのアプリを利用でき、1 回の無効化ですべてのアクセスを停止できます。
インデクサーとダウンロードクライアントを接続する
Chaptarr は標準の arr インデクサーおよびダウンロードクライアントのプロトコルに対応しています。そのため、Prowlarr は Sonarr と同じ方法でインデクサーを Chaptarr に登録できます。通常の torrent クライアントや usenet クライアントも、特別な設定なしで接続できます。
ほとんどの環境で問題になる設定が 1 つあります。Chaptarr からダウンロードクライアントのホストを指定するときは、localhost や 127.0.0.1 を入力しないでください。コンテナ内では、そのアドレスはコンテナ自身を指します。そのため Chaptarr は自身のポート 8080 に接続しようとし、接続できないと報告します。代わりに、コンテナ名の qbittorrent とポート 8080 を使用します。docker network inspect arr を実行して、両方のコンテナが同じネットワーク上にあることを確認してください。このコマンドでは、接続されているすべてのコンテナが名前付きで一覧表示されます。
ダウンロードクライアントが network_mode: "service:gluetun" を使用して VPN コンテナ経由で動作している場合、そのクライアントはネットワーク上に独自の名前を持ちません。Gluetun のネットワーク名前空間を共有するためです。Gluetun が公開しているポートで、gluetun として接続します。この構成と、それに伴うルーティングについては、Gluetun 経由でダウンロードクライアントをルーティングするを参照してください。
Readarr からの移行で発生すること
Chaptarr は Readarr のメタデータソースと互換性がありません。複数のプロバイダーを使う独自の処理パイプラインでタイトル、著者、エディションを解決するため、Readarr が保存した識別子は Chaptarr では意味を持ちません。データベースのインポート機能はなく、そのまま置き換えるアップグレード経路もありません。
既存のライブラリでは、ファイルはそのまま利用できますが、設定は引き継げません。この処理でディスク上の既存ファイルが変更されることはありません。root folder を追加し、ライブラリのインポートを実行すると、Chaptarr は検出したファイルを独自のメタデータと照合します。手動で再構築する必要があるのは、quality profile、命名形式、indexer と client の設定、および Chaptarr が誤って照合したすべての項目です。大規模なライブラリでは手動修正が必要になるため、10 分ではなく 1 晩を見込んでください。
次の順序で実施します。Readarr コンテナを停止しますが、設定ボリュームは保持してください。以前の設定を参照しながら、Chaptarr に再入力できます。まず小さなフォルダー 1 つを Chaptarr に指定し、すべてをインポートする前に照合結果を確認します。問題がないことを確認してから、古いコンテナを削除してください。
ライブラリ全体をスキャンする前に、プライバシーに関して 1 点確認しておきます。メタデータの検索は api2.chaptarr.com に送信されます。README には、これらのリクエストにプロバイダー ID、検索文字列、メディア種別、タグ、ファイル名が含まれる場合があり、完全なパス、ユーザーの識別情報、認証情報は含まれないと記載されています。ファイル名はサーバーの外部へ送信されます。メタデータサービスでは通常の動作ですが、利用するかどうかは意図的に判断してください。
オーディオブックをプレーヤーに渡す
Chaptarr はファイルを整理します。再生は別のプログラムの役割です。通常は Audiobookshelf と組み合わせます。Audiobookshelf はデバイス間で聴取位置を追跡でき、スマートフォン用アプリもあります。公式イメージは ghcr.io/advplyr/audiobookshelf:latest です。公式の Compose 例では、ホストの 13378 番ポートをコンテナの 80 番ポートに公開します。
audiobookshelf:
image: ghcr.io/advplyr/audiobookshelf:latest
container_name: audiobookshelf
ports:
- 127.0.0.1:13378:80
volumes:
- ./abs/config:/config
- ./abs/metadata:/metadata
- /srv/media/audiobooks:/audiobooks
environment:
- TZ=Europe/Berlin
restart: unless-stoppedChaptarr が書き込む同じホストパスをマウントし、Web UI で /audiobooks をライブラリとして追加します。次回のスキャン後に、新しいインポートが表示されます。
すでに Jellyfin を運用している場合は、そのフォルダーをライブラリとして追加して再生できます。ただし、1 つの長いオーディオブックファイルでは、専用のオーディオブックサーバーよりレジューム動作が弱くなります。Jellyfin の設定方法は、VPS で Jellyfin をメディアサーバーとして運用するで説明しています。電子書籍については、/srv/media/ebooks をリーダーアプリケーションに渡します。ファイル名を付けて所定の場所に整理した時点で、Chaptarr の役割は終わります。
保守上のリスク: ライセンス、ランタイム、頻繁に更新されるタグ
Chaptarr は GPL-3.0 ライセンスで提供されています。著作権は Chaptarr の貢献者が保持し、一部には Servarr チームのコードが含まれています。そのため、現在のメンテナーが停止しても、コードはオープンなままで、誰でも再びフォークできます。Chaptarr は .NET 10 を基盤としており、2026 年 8 月時点でランタイムの現行長期サポート版です。つまり、基盤は数か月ではなく数年間サポートされます。来年もこのプロジェクトが存続するかを判断する際は、この 2 つの事実が重要です。
バージョン番号は急速に更新されています。0.9.925 は 2026 年 8 月 9 日に公開され、その後 7 週間でさらに 5 回のリリースがありました。0.9.958 までのすべてのリリースはプレリリースとして公開され、2026 年 9 月 27 日の 0.9.965 が、正式リリースとして初めてマークされた版です。正確なタグを固定してください。latest を使用すると、非対話的な docker compose pull によって 1 週間で複数バージョン先へ更新される可能性があります。また、これほど新しいフォークではリリース間で API が変更されることがあり、その API を前提に作成したスクリプトやダッシュボードが動かなくなります。固定は、自分でホストする新しいプロジェクトすべてに適用する価値のある習慣です。そのため、セルフホストのワークアウトトラッカーとして openGym を実行する手順でも、まったく同じ理由で固定した git タグからデプロイしています。
アップグレードの前には毎回バックアップを取り、計画的にアップグレードしてください。
docker compose stop chaptarr
sudo tar czf chaptarr-config-backup.tgz ./config
docker compose start chaptarrdocker compose pull chaptarr
docker compose up -d chaptarrこのプロジェクトでは、約 6 か月間で 11,000 人を超えるユーザーが利用した中で、データ損失の発生は報告されていません。それでも、バックアップを保持し、失うと困るライブラリを保存先に指定しないよう推奨しています。この 2 つをどちらも重く受け止めてください。設定アーカイブをサーバーの外部にコピーしてください。保護対象と同じディスク上にあるバックアップは、バックアップではないためです。Chaptarr は /config 配下の 1 つの SQLite ファイルに状態を保存するため、この tarball 1 つで十分です。ただし、別のデータベースサーバーを使用している場合は、データベースもダンプする必要があります。Postgres のデータとアップロードファイルを併用する VPS 上で Chatwoot をセルフホストする場合のバックアップ手順も、この構成になります。
障害パターンと表示される文字列
コンテナがループ状態で再起動する。 docker compose ps に Restarting が表示されます。ls -ln ./config を実行します。所有者列の 2 つの 0 は、Docker がディレクトリを root として作成したため、コンテナユーザーがデータベースに書き込めないことを示します。sudo chown -R 1000:1000 ./config を実行します。
インポートが完了せず、ファイルが downloads に残る。 Chaptarr はダウンロードしたファイルを読み取れますが、ライブラリに書き込めません。ls -ln /srv/media/audiobooks を PUID および PGID と比較します。別の UID が所有するディレクトリや、グループが所有していてもグループ書き込み権限がないディレクトリでは、ファイルを移動できません。UMASK=002 により、新規ファイルで後者を防げます。
インポートのたびにディスク使用量が 2 倍になる。 hardlink が作成されず、ファイルがコピーされています。volumes セクションの ln テストを実行します。Invalid cross-device link で終わるエラーが表示されれば、これが確認できます。単一の親ディレクトリをマウントする構成が解決策です。
ダウンロードクライアントに接続できない。 ホストとして localhost を入力しています。コンテナ内では、これは Chaptarr 自身を指します。コンテナ名を使用し、docker network inspect arr で両方のコンテナが一覧に表示されることを確認します。
Compose がサービスの起動を拒否する。 Bind for 127.0.0.1:8789 failed: port is already allocated は、別のプロセスがポートを使用していることを示します。sudo ss -lntp | grep 8789 で使用元を特定します。
ブラウザーに何も表示されない。 ポートを 127.0.0.1 にバインドすると、インターネット経由でラップトップから接続できる待ち受け先がありません。これは意図した動作です。最初に SSH トンネルを開きます。
FAQ
Readarr のライブラリを Chaptarr に移行できますか?
インポートとしては移行できません。Chaptarr は Readarr のメタデータソースに対応しておらず、独自のプロバイダーパイプラインを使用するため、Readarr に保存された識別子には意味がなく、データベース変換もありません。ディスク上のファイルは変更されません。同じパスを root folder として追加し、ライブラリのインポートを実行して、Chaptarr 自身にファイルを照合させます。Quality profile、命名形式、indexer の設定、誤った照合の修正は手作業になるため、すべてをインポートする前に小さなフォルダー1つで試してください。
Chaptarr が audiobook フォルダーに書き込めないのはなぜですか?
コンテナのユーザーに、そのディレクトリへの書き込み権限がありません。通常は、所有者の UID と異なる UID で実行していることが原因です。これらの変数が未設定の場合、Chaptarr は PUID=99 と PGID=100 にフォールバックします。これは unRAID の値であり、通常の Ubuntu VPS では正しくありません。独自の id -u と id -g を設定し、download client でも同じ組み合わせを使用してください。新しいファイルをグループから書き込み可能な状態に保つため、UMASK=002 も設定します。ライブラリのディレクトリで ls -ln を実行して所有権を確認してください。名前ではなく数値が表示されるため、比較できます。
インポート後にディスク使用量が2倍になったのはなぜですか?
Chaptarr はファイルを hardlink できなかったため、コピーしました。/downloads と /audiobooks を別々の bind としてマウントすると、コンテナ内では別々のマウントポイントになります。カーネルはマウントポイントをまたぐ hardlink を拒否し、Invalid cross-device link を返します。/srv/media:/data のような親ディレクトリを1つマウントし、アプリ内では /data/downloads と /data/audiobooks を使用してください。両方のパスが1つのホストファイルシステム上にある必要もあります。df -h で確認できます。
Chaptarr は audiobook を再生できますか?
いいえ。Chaptarr は audiobook を検索、ダウンロード、名前変更、整理しますが、再生は別のプログラムが担当します。一般的な組み合わせは Audiobookshelf です。デバイス間で再生位置を記憶でき、公式イメージ ghcr.io/advplyr/audiobookshelf:latest を使用して、同じホスト上の audiobook パスをマウントします。Jellyfin でもフォルダーをライブラリとして追加すれば再生できますが、1ファイルが長い audiobook ではレジューム動作が弱くなります。
Chaptarr を重要なライブラリで安全に実行できますか?
Chaptarr は新しい fork による beta ソフトウェアです。プロジェクト自身もその点を明記しており、約6か月間、1万1千人を超えるユーザーの環境でデータ損失の報告がないとしています。安心材料は、コードを fork 可能な状態に保つ GPL-3.0 ライセンスと、2026年8月時点で long term support runtime である .NET 10 を基盤としている点です。latest ではなく 0.9.925 のような exact image tag を固定し、アップグレードのたびに /config をバックアップしてください。そのアーカイブはサーバーの外部にも保管します。