VPS向けセルフホストRSSリーダー5選を比較

小規模 VPS に適したセルフホスト型 RSS リーダー

Miniflux は、小規模 VPS に導入するセルフホスト型 RSS リーダーです。PostgreSQL と組み合わせて動作する Go バイナリ 1 つで構成できます。Fever API と Google Reader API に対応しているため、サードパーティー製のスマートフォンアプリから接続できます。アップグレードも docker compose pull 1 つで完了します。拡張機能が必要で、SQLite を内蔵した 1 つのコンテナにまとめたい場合は、FreshRSS を選びます。

VPS のディスク容量を使う価値があるリーダーは、Miniflux、FreshRSS、CommaFeed、yarr、Tiny Tiny RSS の 5 つです。このページでは、これらの実際の違いを比較します。各スタックに必要なメモリ量、使用するデータベース、スマートフォンアプリに必要な同期 API、アップグレード時の動作を確認します。ここに示す数値は、プロジェクトが公開している値か、単純な算術から算出した値のいずれかです。どちらに該当するかは本文で示します。これらは使用するハードウェアのベンチマークではないため、docker stats を使って自分のサーバーを測定してください。

5 つの RSS リーダーを 1 段落ずつ紹介

Miniflux は Go で書かれており、静的コンパイル済みの単一バイナリとして提供されます。ドキュメントでは、唯一の必須依存関係について「PostgreSQL でのみ動作する」と明記されています。SQLite モードはありません。REST API、Fever 互換 API、Google Reader 互換 API に加え、OPML のインポートとエクスポートに対応しています。全文検索は PostgreSQL に委ねられます。これもデータベースを省略できない理由の 1 つです。

FreshRSS は PHP で書かれており、Web サーバーとアプリケーションを 1 つのコンテナで実行します。デフォルトのデータベースは SQLite で、別のサービスは必要ありません。大規模な構成向けに PostgreSQL と MySQL も利用できます。Google Reader API と Fever API に対応しています。インストール手順は VPS への FreshRSS のセットアップ手順 で説明しているため、このページではインストールを繰り返さず、比較に重点を置きます。

CommaFeed は Quarkus 上で動作する Java アプリケーションで、Google Reader に似た構成を採用しています。データベースは実行時ではなくビルド時に選択されます。そのため、プロジェクトはデータベースごとにイメージを公開しています。組み込みの H2 データベース用が athou/commafeed:latest-h2、PostgreSQL 用が athou/commafeed:latest-postgresql で、MySQL と MariaDB 用のバリエーションもあります。これらのタグはネイティブコンパイル版です。-jvm サフィックスが付くものは、代わりに JVM 上で動作するバリエーションです。REST API と Fever 互換 API を公開しています。さらに、version 7.3.0（August 2026）以降は Google Reader 互換 API にも対応しています。

yarr（yet another rss reader）は、SQLite を組み込んだ単一の Go バイナリです。コンテナは必要ありません。通常の ./yarr は 127.0.0.1:7070 で待ち受けます。フラグは簡潔です。-addr 0.0.0.0:7070 -auth alice:secret を指定すると、パスワードで保護した状態でネットワークからアクセスできるようになり、-db /data/yarr.db を指定するとデータベースの保存先を指定できます。Fever 互換 API に対応しています。最新のタグ付きリリースは v2.9 で、September 2026 に公開され、October 2026 に確認されています。その前には June の v2.7 と July の v2.8 があり、再び活発に開発されています。

Tiny Tiny RSS は 5 つの中で最も古く、実行も最も重いソフトウェアです。tt-rss.org の元のプロジェクトは 1 November 2025 に終了しました。現在は github.com/tt-rss/tt-rss のコミュニティフォークで開発が続いており、そのドキュメントが公式のセットアップ手順になっています。この構成は 4 つのサービスで成り立ちます。PostgreSQL コンテナ、PHP-FPM アプリケーションコンテナ、フィードを取得する専用の updater コンテナ、そして前段の nginx コンテナです。ドキュメントには「この構成では PostgreSQL を使用する」と明記されています。独自の JSON API を備えており、Android クライアントと複数のサードパーティーアプリがこの API を利用します。Fever は対応していません。

各スタックに必要なメモリ量

以下の数値は実測値ではなく、予算値です。小規模な VPS で各スタックが超えないようにするメモリ上限を示します。CommaFeed の数値は、プロジェクトが公開している例に基づくもので、コンテナの上限を 256 MB に設定しています。その他の数値は、フィード取得処理のための余裕を残した上限です。フィード取得処理は、更新サイクルの開始時にメモリ使用量が急増します。

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr は、単一のバイナリと 1 つの SQLite ファイルだけで動作し、データベースサーバーや言語ランタイムを必要としないため、128 MB と最も少ないメモリで済みます。Miniflux は 320 MB を 2 個のコンテナで使用し、その大部分は Miniflux ではなく PostgreSQL が占めます。Tiny Tiny RSS は例外的に、640 MB を 4 個のコンテナで使用します。アプリケーション、アップデーター、データベース、Web サーバーが 4 つの独立したプロセスとして動作し、それぞれが独立したヒープを持つためです。

これらの値は、希望値ではなく実際の制限値として設定してください。Docker Compose でのメモリ制限では、構文と、コンテナが上限に達したときの動作を説明しています。制限のないコンテナは、ホストのメモリが枯渇しても穏やかに停止しません。カーネルが停止対象のプロセスを選んで強制終了し、そのプロセスは負荷の原因となったコンテナとは限りません。

読者ごとに必要になるデータベース

この5つで最も大きな運用上の違いはデータベースです。ユーザーインターフェースの違いより重要な判断です。バックアップ手順とアップグレード時のリスクが決まるためです。

Miniflux と公式の Tiny Tiny RSS セットアップでは PostgreSQL が必要です。完全な全文検索と安全な同時書き込みを利用できます。一方で、2つ目のコンテナとボリュームが必要になり、定期的に発生する問題も1つあります。公式の PostgreSQL イメージでは、メジャーバージョン間でデータをその場で移行できません。Tiny Tiny RSS のドキュメントにも明記されており、「公式の PostgreSQL コンテナは、メジャーバージョン間のデータ移行をサポートしていない」と警告しています。フィードリーダーで現実的な選択肢は、古いメジャーバージョンを固定するか、pg_dump と pg_restore を使ってダンプとリストアを行うことです。PostgreSQL では pg_upgrade とレプリケーションベースのアップグレードも説明されています。これらは、停止時間が重要になる大規模データベースでは追加の構成に見合いますが、フィードリーダーのデータベースがその規模になることはほとんどありません。1年または2年に1回はこの作業が必要になる前提で計画してください。

SQLite は FreshRSS のデフォルトであり、yarr のデフォルトでもあります。ファイルは1つだけで、サーバー、ポート、パスワードは必要ありません。数百個程度のフィードを1人で使う限り十分に対応できます。一方、複数のユーザーが同時に書き込むと速度が低下します。その段階で FreshRSS の PostgreSQL オプションが有効になります。yarr は v2.7 でオプションの PostgreSQL サポートを追加しましたが、通常の運用方法は組み込みファイルを使う構成です。

H2 は CommaFeed の組み込みデフォルトです。開始前に検討してください。CommaFeed はイメージのビルド時にデータベースを選択するためです。後から H2 から PostgreSQL に移行する場合、設定を変更するだけでは済みません。別のイメージを用意し、自分でデータ移行を実行する必要があります。1年分の既読履歴を保存する前に決めておきましょう。

スマートフォンアプリは利用できますか

この点は、多くの人が考える以上に重要です。フィードリーダーは、Web インターフェースだけで利用するものではないためです。

Miniflux は Fever compatible API と Google Reader compatible API に対応しているため、ほとんどの iOS および Android クライアントから接続できます。FreshRSS も同じ 2 つの API に対応しており、公式ドキュメントでは対応状況を次のように説明しています。Google Reader API は全機能に対応する「最良」の選択肢です。一方、Fever API は「機能が限定され、効率も低い」動作になります。FreshRSS では、アプリからログインする前に 2 つの設定も必要です。Authentication の下にある「Allow API access (required for mobile apps)」を有効にし、ユーザープロファイルで API password を作成します。API password の作成を省略すると、Web ログインは動作するのにアプリでは認証エラーになります。確認場所を知らないと、原因が分かりにくい状態です。

CommaFeed も現在は両方の API に対応しています。以前から Fever compatible API に対応しており、version 7.3.0 で Fever に対応していないアプリ向けに Google Reader compatible API が追加されました。アプリが Google Reader のみに対応している場合は、7.3.0 以降を使用してください。yarr が公開する API は Fever compatible API のみです。そのため、Fever に対応したクライアントでは動作しますが、Google Reader のみに対応するアプリでは動作しません。Tiny Tiny RSS には独自の API があるため、Tiny Tiny RSS 用に作られたクライアントが必要です。300 個のフィードをインポートする前に、使用するアプリが対象のリーダーに対応していることを確認してください。

1 GB のサーバーで動作する compose ファイル

これは Miniflux スタックです。2026 年 10 月時点のプロジェクト独自の Docker 例を基に調整しています。公開ポートは loopback にバインドし、listen address を明示的に指定しています。両方のコンテナには memory limit も設定しています。

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

このファイルで間違えやすい行は 3 つあります。LISTEN_ADDR=0.0.0.0:8080 は公式イメージが Dockerfile ですでに設定している内容を繰り返すため、miniflux/miniflux と組み合わせても修正ではなく安全策として機能します。独自のイメージをビルドする場合や、パッケージ化されたバイナリを実行する場合には重要です。バイナリに記載されたデフォルト値は 127.0.0.1:8080 だからです。コンテナ内で loopback にバインドされたプロセスには、公開ポート経由で接続できません。そのため、コンテナが正常に見えても connection reset が発生します。ボリュームのパス /var/lib/postgresql は PostgreSQL 18 に対応しています。version 17 以前ではデータが /var/lib/postgresql/data に保存されます。誤ったパスをマウントすると、データディレクトリがボリューム上に配置されません。そのため、コンテナを次に再作成したときにデータがすべて消えます。127.0.0.1:8080:8080 により、ポートを public internet に公開せずに済みます。アドレスを指定せずにポートを公開すると、ufw が管理しない chain にルールが追加されるためです。Docker のポートが ufw を迂回する仕組みでは、その動作を説明しています。TLS を前段に置くには、Traefik の reverse proxyを使用します。

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps には、両方の service が running として表示され、database には healthy が付くはずです。Miniflux の初回起動では schema migration がログに記録されます。これは RUN_MIGRATIONS=1 が実行する処理です。docker stats --no-stream は現在の memory 列を表示します。この値を、上の表にある上限値と比較します。Miniflux コンテナが再起動を繰り返す場合は、ログを確認してください。connect: connection refused は、PostgreSQL が接続を受け付ける準備を終える前に起動したことを示します。これは service_healthy condition が防ぐ状態です。そのため、編集後も condition が維持されているか確認してください。Compose 自体に慣れていない場合は、VPS での Docker Compose の基本で、まずファイル構成を確認できます。

1 GB のサーバーに収まらないもの

Tiny Tiny RSS は避けるべきです。公式の 4 サービス構成は、VPS 上で他に何も動かさない場合に限り、1 GB の VPS で動作します。別のデータベース接続型アプリケーションやリバースプロキシと同居させると動作しません。4 つのサービスには 4 つ分のオーバーヘッドがあり、そのうち 1 つは PostgreSQL です。

CommaFeed は収まりますが、H2 イメージを使用し、プロジェクト独自の例で設定されている 256 MB の上限を設ける必要があります。小規模なサーバーで問題になるのは、CommaFeed を別のデータベースサーバーと同居させる構成です。-jvm のイメージバリアントを使うと、さらに厳しくなります。プロジェクトのドキュメントによると、JVM はデフォルトでメモリを多く消費し、未使用のメモリをオペレーティングシステムへ返さないためです。latest-h2 と latest-postgresql のタグはネイティブビルドです。プロジェクトはメモリ使用量が少ないため、これらを推奨しています。JVM を実行する理由がない限り、これらを使用してください。

サーバーのメモリが不足すると、カーネルの OOM killer がプロセスを選択して終了させます。dmesg -T には Out of memory: Killed process 1234 (java) のような行が表示されます。アプリケーションがログを書き込む前に終了するため、アプリケーションログには何も表示されないまま、コンテナは docker compose ps から消えます。

各サービスのアップグレード時の動作

• Miniflux: docker compose pull && docker compose up -d。RUN_MIGRATIONS=1 が設定されている間、起動時にスキーマ移行が適用されます。アップグレードで注意すべき対象は Miniflux ではありません。その下で動作する PostgreSQL のメジャーバージョンです。
• FreshRSS: 新しいイメージを pull します。SQLite ではアップグレードするデータベースエンジンがないため、通常の問題は、更新に追随していないサードパーティー拡張機能で発生します。
• CommaFeed: データベースに対応するイメージバリアントを pull します。latest-h2 から latest-postgresql への切り替えでは、データは引き継がれません。
• yarr: バイナリを置き換え、データベースファイルはそのまま保持します。2026 年 6 月、7 月、9 月にリリースがあり、2026 年 10 月時点では v2.9 が最新です。そのため、時々リリースページを確認してください。
• Tiny Tiny RSS: docker compose pull && docker compose up -d。アプリケーションコンテナは起動時に自身を更新します。プロジェクトの FAQ では、スキーマ更新エラーの原因として、壊れた volume または override 設定が挙げられています。エラーが発生した場合は、まずこれらを確認してください。compose ファイルが廃止された tt-rss.org プロジェクトのイメージをまだ pull している場合は、fork のイメージに切り替えます（Docker Hub の supahgreg/tt-rss または ghcr.io/tt-rss/tt-rss）。

これらの作業を行う前に、必ずデータベースを dump してください。作業後ではありません。

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

リフレッシュ間隔にかかる帯域幅

以下の数値は実測値ではなく、算術計算によるものです。100 個のフィードを対象に、各間隔でフィードごとに 1 回リクエストし、レスポンスが 40 KB であると仮定しています。サーバーが条件付きリクエストに対応している場合、実際の通信量は少なくなります。フィードに記事本文全体が含まれる場合は、通信量が多くなります。

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

100 個のフィードを 5 分間隔で取得すると、1 か月あたり 864,000 リクエスト、約 34.6 GB になります。1 時間間隔では 72,000 リクエスト、約 2.9 GB です。Miniflux は POLLING_FREQUENCY を 60 分に設定して出荷されます。これはグラフの最後の行に該当し、ほとんどの環境ではこのデフォルト設定で問題ありません。取得頻度を上げても、記事が早く届くわけではありません。

実際の数値を算術計算より低く抑えるのが、条件付きリクエストです。フィードが返した ETag と Last-Modified のヘッダーをリーダーが保存している場合、次回はそれらを If-None-Match と If-Modified-Since として送り返します。新しい内容がないサーバーは、本文なしで 304 Not Modified を返します。接続にはハンドシェイクのコストがかかりますが、ペイロードは転送されません。条件付きリクエストを無視するフィードは、毎回ドキュメント全体を返します。そのため、サイズの大きいフィードが少数あるだけで、転送量の大部分を占めることがあります。

過度に頻繁なポーリングは、ブロックの原因にもなります。サーバーが過剰なアクセスと判断すると 429 Too Many Requests を返し、サイトによっては代わりに 403 を返します。Miniflux はフィードごとに最後のエラーを記録します。そのため、他のフィードは更新されているのに 1 つのフィードだけ更新されなくなった場合は、最初にフィード一覧を確認します。

フィードは消滅する。OPML ファイルはバックアップではない

フィードは想定より早く使えなくなります。ドメインの有効期限が切れたり、サイトがフィードを提供しないプラットフォームへ移行したり、以前は XML を返していた URL が 200 OK ステータスの HTML エラーページを返すようになったりします。最後のケースは扱いにくい例です。取得自体は成功しますが、解析に失敗するため、リーダーにはネットワークエラーではなく解析エラーとして記録されます。年に 1 回、フィード一覧を最終更新日時で並べ替え、長期間更新されていないものを削除してください。

OPML エクスポートは購読一覧です。標準的な OPML ファイルには、フィード URL とフォルダー名が含まれます。FreshRSS は独自の XML namespace を追加し、フィードごとの更新間隔、XPath によるスクレイピングセレクター、自動既読フィルターなどの設定も保持します。ただし、OPML エクスポートには既読状態、スター付き記事、保存した記事本文は含まれません。その OPML を新しいインストールへインポートすると、フィードは復元されますが、これまでに読んだすべての記事が再び未読として扱われます。

重要なバックアップ対象はデータベースです。PostgreSQL では、上記の pg_dump コマンドだけで完了します。FreshRSS や yarr などの SQLite リーダーでは、書き込み処理を停止してファイルをコピーするか、実行中に sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" を使って一貫性のあるコピーを取得します。書き込み中のデータベースに対する単純な cp では、後から開けないファイルが生成されることがあります。コピー時点で書き込みが途中までしか反映されないためです。次に、それらのファイルをスケジュールに従ってサーバー外へ転送します。VPS 上の restic バックアップはそのために利用します。少なくとも 1 回はスクラッチコンテナへ復元し、手順が機能することを確認してください。

フィードリーダーは自分で運用できるサービスの中でも特に低コストです。そのため、2026 年にセルフホストする価値があるものの一覧には必ず登場します。隣にセルフホストした SearXNG インスタンスを配置すれば、読書も検索も自分で管理するハードウェア上で行えます。

FAQ

メモリ使用量が最も少ないセルフホスト型 RSS リーダーはどれですか？

yarr です。SQLite を組み込んだ単一の Go バイナリであるため、データベースサーバーも別の言語ランタイムも必要ありません。128 MB の上限で余裕を持って運用できます。トレードオフは機能です。Fever API のみを扱い、最新リリースは 2026 年 9 月の v2.9 です。Google Reader API と全文検索を同程度のメモリ使用量で利用したい場合は、320 MB で動作する Miniflux と PostgreSQL の構成が適しています。

1 GB の VPS でセルフホスト型 RSS リーダーを実行できますか？

はい。両方のコンテナに mem_limit を設定すれば、Miniflux と PostgreSQL は約 320 MB に収まり、FreshRSS と SQLite は 1 つのコンテナで動作します。1 GB 環境で避けるべきなのは公式の Tiny Tiny RSS スタックです。独自の PostgreSQL を含め、4 個のサービスで構成されるためです。必ずメモリ上限を設定してください。容量を使い切ったホストでコンテナに上限がないと、カーネルがプロセスを強制終了します。その際、問題のあるアプリケーションではなくデータベースが選ばれることがよくあります。

これらのうち、iOS と Android の RSS アプリで動作するものはどれですか？

Miniflux、FreshRSS、CommaFeed 7.3.0 以降は、Fever 互換 API と Google Reader 互換 API の両方に対応しているため、ほぼすべてのモバイルクライアントから接続できます。yarr は Fever API のみを提供します。Tiny Tiny RSS は独自 API を使用するため、専用に構築されたクライアントが必要です。FreshRSS では、Authentication の下で API access も有効にし、プロフィールで別の API パスワードを設定する必要があります。設定しないと、Web サイトは動作していてもアプリのログインに失敗します。

OPML のエクスポートは RSS リーダーのバックアップになりますか？

いいえ。OPML で購読リストを再構築できます。FreshRSS の拡張エクスポートには、フィードごとの設定とフィルターも含められます。しかし、既読状態、スター付き項目、記事本文はすべてデータベースに保存されています。PostgreSQL では pg_dump を、SQLite では .backup コマンドを使用してデータベース自体をバックアップし、結果をサーバー外にもコピーしてください。

Miniflux は SQLite に対応していますか？

いいえ。プロジェクトのドキュメントには「PostgreSQL でのみ動作する」と記載されています。全文検索も PostgreSQL の機能を使用して実装されているため、より軽量なモードに切り替えることはできません。データベース用のコンテナをまったく使用しないフィードリーダーが必要な場合は、デフォルトの SQLite バックエンドで FreshRSS を実行するか、組み込みファイルを使用する yarr を実行してください。