小型VPS自托管RSS阅读器对比：Miniflux与FreshRSS

小型 VPS 适合使用哪款自托管 RSS 阅读器

Miniflux 是适合部署在小型 VPS 上的自托管 RSS 阅读器。它是一个 Go 二进制文件，与 PostgreSQL 配合运行。它支持 Fever 和 Google Reader API，因此第三方手机应用可以连接；升级只需执行一个 docker compose pull。如果您需要扩展，以及一个内置 SQLite 的容器，请改用 FreshRSS。

有 5 款阅读器值得占用 VPS 的磁盘空间：Miniflux、FreshRSS、CommaFeed、yarr 和 Tiny Tiny RSS。本页比较它们实际存在的差异：每个软件栈所需的内存、各自要求使用的数据库、手机应用所需的同步 API，以及升级时会发生什么。本文中的每个数据要么由项目公开，要么是简单计算得出，并会明确说明来源。这些数据都不是针对您硬件的基准测试，因此请使用 docker stats 测量您自己的服务器。

五款阅读器，每款各用一段介绍

Miniflux 使用 Go 编写，以单个静态编译二进制文件的形式发布。其文档明确说明，它唯一的硬性依赖是“只能使用 PostgreSQL”。它不提供 SQLite 模式。它提供 REST API、兼容 Fever 的 API 和兼容 Google Reader 的 API，还支持 OPML 导入和导出。全文搜索交由 PostgreSQL 处理，这也是数据库不可选用的原因之一。

FreshRSS 使用 PHP 编写，以单个容器运行 Web 服务器和应用程序。SQLite 是默认数据库，不需要额外服务；对于规模更大的部署，也支持 PostgreSQL 和 MySQL。它支持 Google Reader API 和 Fever API。FreshRSS 在 VPS 上的部署教程已经介绍了安装过程，因此本页只进行比较，不再重复安装步骤。

CommaFeed 使用基于 Quarkus 的 Java 编写，其界面布局仿照 Google Reader。它在构建时而不是运行时选择数据库，因此项目会针对每种数据库发布一个镜像：athou/commafeed:latest-h2使用内置的 H2 数据库，athou/commafeed:latest-postgresql使用 PostgreSQL，另外还有适用于 MySQL 和 MariaDB 的变体。它提供 REST API 和兼容 Fever 的 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.8，发布于 2024 年 7 月；截至 2026 年 8 月检查时，应将其视为已完成的软件，而不是仍在积极开发的软件。

Tiny Tiny RSS 是这五款中历史最久、运行负担也最重的一款。官方 Docker 配置包含四个服务：PostgreSQL 容器、PHP-FPM 应用容器、负责抓取订阅源的独立更新容器，以及前端的 nginx 容器。文档明确说明“此配置使用 PostgreSQL”。它提供自己的 JSON API，Android 客户端和多个第三方应用都通过该 API 访问。它不支持 Fever。

每个堆栈需要多少内存

下面的数值是预算，不是测量结果：它们表示每个堆栈在小型 VPS 上应保持低于的内存上限。CommaFeed 的数值来自项目公开发布的示例，该示例将容器限制为 256 MB。其他数值是为 feed fetcher 留出余量后的上限，因为刷新周期开始时，通常是它产生内存峰值。

[
  {
    "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 的内存占用最低，为 128 MB，因为它只有一个二进制文件和一个 SQLite 文件，不需要数据库服务器或语言运行时。Miniflux 在 2 个容器中需要 320 MB，其中大部分内存由 PostgreSQL 使用，而不是由 Miniflux 使用。Tiny Tiny RSS 则是例外，在 4 个容器中需要 640 MB，因为应用、更新程序、数据库和 Web 服务器是4个独立进程，各自拥有独立的堆。

请将这些数值设置为实际限制，而不是仅凭预期。Docker Compose 中的内存限制介绍了相关语法，以及容器达到上限时的行为。未设置限制的容器不会在主机内存耗尽时优雅失败：内核会选择一个进程并将其终止，而且被终止的进程通常不是导致内存压力的容器。

每个读者强制您使用哪种数据库

数据库是这五个应用之间最大的运维差异。它比用户界面的任何差异都更重要，因为它决定备份流程和升级风险。

Miniflux 和官方 Tiny Tiny RSS 部署都要求使用 PostgreSQL。它提供真正的全文搜索和安全的并发写入。但您需要额外运行一个容器、配置一个卷，还要处理一个周期性问题：官方 PostgreSQL 镜像无法在原地迁移不同主版本之间的数据。Tiny Tiny RSS 文档对此有明确说明，并警告“官方 PostgreSQL 容器不支持在不同主版本之间迁移数据”。实际可行的方案是固定使用旧主版本，或者使用 pg_dump 和 pg_restore 执行转储和恢复。请按每一到两年执行一次迁移来规划。

SQLite 是 FreshRSS 和 yarr 的默认数据库。它只需要一个文件，不需要服务器、端口或密码。对于只有一个用户且订阅源数量为几百个的场景，SQLite 表现良好；当多个用户同时写入时，性能会下降，这时 FreshRSS 的 PostgreSQL 选项开始体现价值。yarr 在 v2.7 中增加了可选的 PostgreSQL 支持，但使用内置文件仍是常规部署方式。

H2 是 CommaFeed 默认的内置数据库。在开始部署前，您应认真考虑这一点，因为 CommaFeed 会在构建镜像时选择数据库。之后从 H2 切换到 PostgreSQL 并不是修改配置，而是更换镜像并自行执行数据迁移。因此，请在服务器中积累一年的阅读历史之前做出决定。

手机应用能否正常使用

这个问题的影响比许多人预期的更大，因为 Web 界面只是使用订阅源阅读器的一部分。

Miniflux 提供兼容 Fever 的 API 和兼容 Google Reader 的 API，因此大多数 iOS 和 Android 客户端都能连接。FreshRSS 也提供这两种 API，并在其文档中说明了两者的优先级：Google Reader API 的功能支持最完整，属于“最佳”选项；Fever API 则存在“功能有限且效率较低”的问题。FreshRSS 还需要先完成两个步骤，应用才能登录。进入 Authentication，启用“Allow API access (required for mobile apps)”，然后在用户配置文件中创建 API 密码。如果跳过 API 密码，应用会出现身份验证失败，但 Web 登录仍然正常。这种情况在了解检查位置之前容易造成困惑。

CommaFeed 和 yarr 都只提供兼容 Fever 的 API，不提供其他 API。因此，它们可以与支持 Fever 的客户端配合使用，但不能与只支持 Google Reader 的应用配合使用。Tiny Tiny RSS 则使用自己的 API，因此需要使用专为它编写的客户端。在将 300 个订阅源导入之前，请确认您常用的应用支持该阅读器。

1 GB 服务器上可正常运行的 Compose 文件

这是 Miniflux 堆栈，基于该项目截至 August 2026 的 Docker 示例调整而来。发布的端口绑定到 loopback，监听地址已显式设置，两个容器也都设置了内存限制。

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:

该文件中有三行最容易写错。设置 LISTEN_ADDR=0.0.0.0:8080 是因为该二进制文件文档中的默认值为 127.0.0.1:8080；而容器内绑定到 loopback 的进程无法通过发布端口访问，因此容器看起来运行正常，但连接会被重置。卷路径 /var/lib/postgresql 与 PostgreSQL 18 匹配；版本 17 及更早版本将数据存储在 /var/lib/postgresql/data 中。挂载错误的路径意味着数据目录根本不在卷上，因此下次重新创建容器时，所有数据都会消失。127.0.0.1:8080:8080 可使端口不暴露到公网，因为发布端口时不指定地址，会向 ufw 不管理的链中写入规则。Docker 端口会绕过 ufw 解释了这一机制，Traefik 反向代理 可用于在其前面配置 TLS。

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

docker compose ps 应显示两个服务都在运行，并将数据库标记为 healthy。Miniflux 首次启动时会记录架构迁移日志，这正是 RUN_MIGRATIONS=1 触发的操作。docker stats --no-stream 会输出实时内存列，该数值应与上方图表中的限制进行比较。如果 Miniflux 容器不断重启，请查看其日志：connect: connection refused 表示它在 PostgreSQL 准备好接受连接之前就已启动，这正是 service_healthy 条件所避免的问题，因此请检查编辑文件后该条件是否仍然存在。如果你还不熟悉 Compose，VPS 上的 Docker Compose 基础 会先介绍文件布局。

1 GB 服务器无法容纳的内容

Tiny Tiny RSS 是应跳过的选项。它的官方四服务架构可以运行在 1 GB VPS 上，但前提是该 VPS 不运行其他服务。它无法与另一个依赖数据库的应用和反向代理并行运行。四个服务意味着四份开销，其中一个还是 PostgreSQL。

CommaFeed 可以运行，但只能使用 H2 镜像，并设置项目示例中的 256 MB 上限。会让小型服务器无法承受的组合，是 JVM 与独立数据库服务器并存，因为 JVM 会占用你留下的所有内存余量。CommaFeed 文档将 -Xmx256m 标为硬限制，并将 OpenJ9 称为“比 HotSpot JVM 更节省内存的替代方案”，这说明了内存主要消耗在哪里。

服务器耗尽内存时，内核的内存不足杀手会选择一个进程并终止它。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：拉取新镜像。使用 SQLite 时无需升级数据库引擎，因此通常的故障来源是未及时适配的第三方扩展。
• CommaFeed：拉取与数据库匹配的镜像变体。从 latest-h2 切换到 latest-postgresql 不会迁移数据。
• yarr：替换二进制文件，保留数据库文件。由于自 2024 年 7 月的 v2.8 后没有新版本（截至 2026 年 8 月检查），通常无需升级。
• Tiny Tiny RSS：docker compose pull && docker compose up -d。数据库架构迁移会自动运行；需要确认迁移时，界面会将您重定向到迁移页面。

在执行上述任何升级前都应创建数据库转储，不要等到升级后再创建。

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 分钟刷新一次，每月会产生 864,000 次请求，流量约为 34.6 GB。每小时轮询一次会产生 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 会将最近一次错误记录在订阅源自身上。因此，当一个订阅源停止更新而其他订阅源仍正常工作时，应首先查看订阅源列表。

订阅源会失效，OPML 文件不是备份

订阅源失效的速度可能超出预期。域名会过期，网站会迁移到不提供订阅源的平台，原本提供 XML 的 URL 可能开始返回带有 200 OK 状态码的 HTML 错误页面。最后一种情况最难处理：获取请求成功，但解析失败，阅读器记录的是解析错误，而不是网络错误。每年检查一次订阅源列表，按最后更新时间排序，并删除长期没有更新的订阅源。

OPML 导出文件只是订阅列表。它包含订阅源 URL 和文件夹名称，但不包含已读状态、加星文章、每个订阅源的设置、过滤规则或保存的文章正文。将 OPML 导入全新安装后，订阅源会恢复，但之前读过的所有文章都会再次标记为未读。

真正重要的是数据库备份。对于 PostgreSQL，上面的 pg_dump 命令即可完成整个备份过程。对于 FreshRSS 或 yarr 这类使用 SQLite 的阅读器，应先停止写入进程再复制数据库文件；也可以在服务运行时使用 sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" 创建一致副本。正在写入的数据库如果直接执行 cp，可能生成之后无法打开的文件，因为复制内容可能包含尚未完成的写入。然后按计划将这些文件推送到服务器之外，这正是 VPS 上的 restic 备份的用途。至少将其中一个备份恢复到临时容器中，确认恢复流程确实可用。

订阅源阅读器是最容易自行部署的服务之一，因此它会出现在所有2026 年值得自行托管的服务列表中。在旁边部署自行托管的 SearXNG 实例，阅读和搜索都可以在您控制的硬件上完成。

FAQ

哪个自托管 RSS 阅读器占用的内存最少？

yarr。它是一个内置 SQLite 的单一 Go 二进制文件，因此不需要数据库服务器，也不需要额外的语言运行时；128 MB 的上限足够使用。代价是维护和功能较少：它最新的版本是 2024 年 7 月发布的 v2.8，并且只支持 Fever API。如果您希望使用开发活跃且资源占用相近的项目，Miniflux 搭配 PostgreSQL 并将内存限制设为 320 MB 是更好的选择。

可以在 1 GB VPS 上运行自托管 RSS 阅读器吗？

可以。为两个容器都设置 mem_limit 后，Miniflux 搭配 PostgreSQL 的内存占用可控制在约 320 MB 内；FreshRSS 搭配 SQLite 可运行在单个容器中。在 1 GB VPS 上应避免使用官方 Tiny Tiny RSS 堆栈，因为它包含 4 个服务，其中包括自带的 PostgreSQL。务必设置内存限制，因为内存已耗尽的主机上，无限制的容器会触发内核杀死进程，而被选中的通常是数据库进程，而不是有问题的应用进程。

这些 RSS 阅读器中，哪些支持 iOS 和 Android RSS 应用？

Miniflux 和 FreshRSS 同时支持兼容 Fever 的 API 和兼容 Google Reader 的 API，因此几乎所有移动客户端都能连接。CommaFeed 和 yarr 只提供 Fever API。Tiny Tiny RSS 使用自有 API，因此需要使用专为它开发的客户端。在 FreshRSS 中，您还必须在 Authentication 下启用 API 访问，并在个人资料中设置单独的 API 密码；否则应用会登录失败，但网站仍可正常使用。

OPML 导出是 RSS 阅读器的备份吗？

不是。OPML 保存订阅源 URL 和文件夹，因此只能重建订阅列表，其他内容都不会保留。已读状态、加星项目、过滤规则和文章正文都保存在数据库中。请使用 pg_dump 备份 PostgreSQL 数据库，或使用 .backup 命令备份 SQLite 数据库，然后将结果复制到服务器之外。

Miniflux 支持 SQLite 吗？

不支持。项目文档说明它“仅支持 PostgreSQL”，全文搜索也使用了 PostgreSQL 的功能，因此没有更轻量的模式可切换。如果您希望使用完全不需要数据库容器的 RSS 阅读器，可以运行默认使用 SQLite 后端的 FreshRSS，或运行使用嵌入式文件的 yarr。