Readdig 開源 RSS 與 Podcast 閱讀器：自架前能從 repo 核對的設計事實

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Readdig 是一套以 Apache-2.0 授權開源的 RSS 訂閱與 Podcast 播放閱讀器，repo 放在 GitHub 的 readdig/readdig，可以用 Docker Compose 自架在一台自己掌控的伺服器上，把手裡散落在各種服務的訂閱源收回到同一個介面。它同時是一個 PWA（漸進式網頁應用），裝到手機或桌面後用起來接近原生效能；開發者自己也在 readdig.com 架了一個託管版本，提供註冊帳號與試用。這篇文章的範圍只到 repo 原始碼與官方網站能核對的設計事實，實際部署後的 feed 抓取成功率、穩定度與 UI 順暢度不在這次的核對範圍裡，會在文末明確標出來。

Pin

想讓閱讀器直接收各平台熱榜源的人，可以參考糖果夢熱榜：它幫 379 個平台各自產出 RSS 訂閱網址，挑幾條加進 Readdig 這類閱讀器就能收。

不想顧一整套伺服器棧、只想要現成訂閱源的話，News Agent 這類掛在 GitHub Actions 上的新聞聚合管線用排程產生 RSS 訂閱檔再經 Pages 上站，是輕量許多的另一條路。

想追蹤微信公眾號的中文 AI 開發消息，開放 RSS 格式難以涵蓋，AI情報站 提供了每日聚合的網頁 Feed 作為補充入口。

想把收聽範圍從自己訂閱的 Podcast 擴大到中國大陸的廣播電台、戲曲與相聲，雲聽 radio.cn 是另一個可考慮的入口。

會挑 Readdig 來寫，是因為它的 repo 比 readdig.com 的行銷頁面講得多更多。readdig.com 首頁用一句標語帶過定位（「A PWA platform RSS reader and podcasts player」），再加一個註冊與試用入口；但要判斷這套閱讀器適不適合自架，真正有用的資訊在 GitHub。README、環境變數表、依賴清單、commits 紀錄相當完整，最新版本推進到 v1.3.16（2026 年 6 月 25 日），327 顆 star、19 個 fork，一週內可以連著推 16 個版本。判斷自架可行性真正需要的資訊都在 GitHub，下面把 repo 能直接核對的事一層層拆開來講。

Pin

repo 比行銷頁面說得更完整的定位

先把它跟同類工具擺在一起看。RSS 閱讀器這個品類已經有 不少 AI 聚合型的新選擇，也有像 FeedCraft 這種夾在 reader 與 source 之間的 RSS 中介層。Readdig 走的不是聚合或中介路線，而是傳統的「自架一個閱讀器」這個位置：你自己架服務、自己管訂閱清單、自己掌握歷史資料。

README 開頭給的定位只有一句：「Readdig is an RSS and Podcast reader application」。這句話本身沒什麼資訊量，但對照環境變數表與依賴清單，能看出它想做的事情比字面上大。具體來說，repo 顯示它整合了四個方向的能力：RSS 訂閱、Podcast 播放、社群討論串聚合（這點稍後會講到 V2EX 與 Hacker News），以及一個給多租戶情境預留的 Paddle 付費接口。

授權部分值得獨立確認一次，因為「開源」兩個字本身沒有標明具體授權。直接查 repo 的 license 欄位與 app/package.json，兩邊都寫的是 Apache-2.0。Apache-2.0 是相對寬鬆的授權，允許商業使用、修改、散布、甚至做成付費產品，附帶專利授權條款。對個人自架沒有任何限制，對想把 Readdig 包成服務給客戶用的人也保留了空間。

架構與部署：Node + React + PostgreSQL + Redis 的四件式組合

Readdig 的 README 把架構拆成四個元件，這個拆法直接決定了你部署時要準備哪些服務、VM 規格要抓多少。

API 層是 Node.js，用 Express 框架，README 要求 Node 18.20.8 以上。前端是 React 17，用 Create React App（CRA 5）打包，這在 app/package.json 的 react-scripts 依賴裡可以核對。資料庫是 PostgreSQL 12 以上，快取與任務佇列都丟給 Redis 6 以上，佇列系統用的是基於 Redis 的 Bull。

整套服務的部署路徑是 Docker Compose。README 的 Docker Deployment 段寫得很清楚：不用自己 build image，直接拉 GitHub Container Registry（GHCR）上的預建映像，步驟大致是 clone repo 取得設定檔、複製 docker-compose.example.yml 改密碼與網域、選擇性掛上 Nginx 反向代理、docker compose up -d 把容器跑起來。完成後打 /health 這個 endpoint，回傳 {"status":"ok"} 就代表 API 服務正常啟動。

開發環境的路徑則分 API 與前端兩邊各跑一套：API 是 yarn install、複製 .env.example、yarn db:migrate、yarn dev（跑在 port 8000）；前端是 yarn install、複製 .env.example、yarn start（跑在 port 3000）。生產部署走 GHCR 映像會比本機 build 乾淨，這也是 README 推薦的路徑。

需要先準備好的外部服務只有三個：PostgreSQL、Redis、一台能跑 Docker 的機器。如果你想把它跟其他 區域網路自架服務 放在同一台 VM 上，要注意的是 PostgreSQL 與 Redis 都會佔記憶體，加上 Node API 本身，建議 VM 規格至少抓 2GB RAM 起跳， feed 量大或訂閱源多時再往上加。

它確實是 PWA：證據藏在依賴清單裡

Readdig 的 README 全文沒有出現「PWA」這個詞，這也是一開始讓人猶豫的地方：它到底算不算 PWA？要確認這個說法成不成立，得直接進 app/package.json 看依賴。

答案在 dependencies 裡。Readdig 的前端一共引入了 12 個 Workbox v6 系列套件，包括 workbox-precaching（資源預快取）、workbox-routing（請求路由）、workbox-strategies（快取策略）、workbox-background-sync（背景同步）、workbox-navigation-preload（導覽預載）、workbox-expiration（快取過期）等等，另外還有一個 @3m1/service-worker-updater 負責 service worker 更新通知。Workbox 是 Google 維護的 PWA service worker 標準庫，整套掛上去等於把離線快取、背景同步、資源預載這套 PWA 能力整個裝起來。

所以 PWA 這個說法是成立的，而且 readdig.com 的首頁標語也直接寫了「A PWA platform RSS reader」，官方定位與程式碼依賴兩邊對得起來。實際帶來的效果是：讀者可以把 Readdig 安裝到桌面或手機主畫面，用起來像原生 app，不再是瀏覽器分頁那種隔層感；已經造訪過的文章會被 service worker 快取，斷網時還能讀。對 RSS 閱讀器這種「通勤時想翻一下已下載文章」的場景，PWA 的離線能力是有實際意義的。

免費模式預設開啟，付費整合是另一條獨立開關

Readdig 的商業模式設計值得單獨看清楚，因為它的環境變數表裡同時出現了 FREE_MODE 與 Paddle 兩個東西，容易讓人誤會它是半商業化的 SaaS。

README 的環境變數說明把 FREE_MODE 描述為「enabled by default, set to false to enable paid plans」。也就是說，你把 Readdig 架起來之後，預設就是完全免費、所有功能開放；只有在你主動把 FREE_MODE 設成 false 時，Paddle 付費整合才會啟用，開始接收訂閱付款。Paddle 的設定是另一組獨立的環境變數（PADDLE_PUBLIC_KEY、PADDLE_API_URL、PADDLE_VENDOR_ID、PADDLE_VENDOR_AUTH_CODE），不填就不會啟動。

這個設計的實際意義是：你自己架的實例完全免費、沒有功能閹割，Paddle 那條路是留給想把 Readdig 架成多租戶服務、收費提供給別人使用的人。值得注意的是，開發者自己在 readdig.com 經營的託管版本首頁放了「START TRIAL」按鈕，連到 /signup 註冊頁，這暗示官方託管站可能就是把 FREE_MODE 關掉、改走 Paddle 收費的那個部署。不過託管方案的具體定價、試用時長、方案差異，readdig.com 上並沒有公開揭露，要註冊進去才看得到，本文沒有實際註冊驗證這一層。

把自架與託管兩條路擺在一起看：自架的人享受 Apache-2.0 授權下的完全免費與資料自主；想省事的人可以在 readdig.com 註冊試用開發者經營的託管版，但那是一個商業服務，條款與定價要自己進去確認。兩者跑的是同一套原始碼，差別只在誰管伺服器。

超過 RSS：V2EX 與 Hacker News 的社群聚合

從環境變數表與近期的 commits 紀錄來看，Readdig 的訂閱能力其實超過傳統 RSS。這是 README 的 Features 段沒有特別強調、但程式碼裡寫得很明白的一層。

環境變數表裡有一組 V2EX 相關設定：V2EX_TOKEN、V2EX_BASE_URL、V2EX_REPLIES_TTL（快取 TTL，預設 30 分鐘）。另一組是 Hacker News 相關：HN_BASE_URL、HN_COMMENTS_TTL。再翻 commits 紀錄，2026 年 6 月下旬有一連串 feat(linuxdo)、refactor(v2ex) 相關的提交，包括「support threaded replies by saving parentReplyId」「prioritize RSS for fetching replies, JSON as supplement」。

把這些拼起來看，Readdig 不只訂閱 RSS feed，還能把 V2EX、Hacker News、LinuxDo 這類社群平台的討論串抓進來，顯示在文章底下的回覆區。對習慣在這些社群追技術討論的讀者來說，這個能力是把「讀文章」與「看社群怎麼討論這篇文章」整合在同一個介面，而不是在 reader 與瀏覽器之間來回切換。

要留意的是，V2EX 的整合需要你自己申請 V2EX_TOKEN（V2EX 的 API token），沒有 token 這條路就不會啟用。Hacker News 的部分則是透過 Algolia 的搜尋 API 抓評論，不需要額外認證。這層社群聚合是 Readdig 跟一般 RSS reader 比較明顯的差異點，但它的實際抓取品質與穩定度需要實際跑一輪才有辦法判斷。

OPML 匯入匯出與內容組織

對已經在用其他閱讀器的人來說，搬家可行性往往比功能列表更重要。Readdig 的 Features 段明確列出 OPML import/export，也就是說你可以從 Feedly、Inoreader、Topfeed 或任何支援 OPML 的閱讀器把訂閱清單匯出，再匯入 Readdig。反向也能匯出，不會被綁死。

訂閱源的分類方式是資料夾加上標籤，文章的個人化標記則是「article starring」（文章收藏）與閱讀歷史。值得一提的是，有些介紹文章會把 starring 寫成「Bookmarks（書籤）」，概念上接近，但 repo 用詞是 starring，這裡照 repo 原文標出來避免混淆。整體的內容組織邏輯跟主流閱讀器差不多，沒有特別突出的分類創新，但該有的都有。

這份 repo 還回答不了的事

誠實講清楚 repo 看不到的部分，比列一大串功能更有用。下面這幾項是這篇文章沒辦法從原始碼層級確認的，需要你實際部署後才會知道。

feed 抓取的成功率與更新頻率是其一。README 沒有給出 feed 輪詢間隔的具體數字，Bull 佇列的排程邏輯要進 api/ 原始碼才看得到，這次沒有逐行讀。如果你訂閱的源很多、又包含一些不穩定的 feed，實際抓取品質只能部署後觀察。

UI 順暢度與互動設計是其二。readdig.com 首頁本身是這套軟體的託管實例，註冊帳號進去就能看到實際介面，但首頁沒有放任何產品截圖或功能展示，README 也沒有附介面截圖。React 17 加 CRA 5 的技術組合在 2026 年已經算偏舊（React 17 是 2020 年的版本），但這不代表介面不好用，只是技術選型相對保守。實際的閱讀體驗、Podcast 播放器操作、手機 PWA 的流暢度，都需要註冊或自架跑起來才知道。

郵件通知的實際行為也講不清楚。環境變數表有 EMAIL_BACKEND 與 EMAIL_SENDGRID_SECRET，表示它透過 SendGrid 寄信。但「什麼時候寄、寄哪些事件、能不能關掉」這些行為層的問題，README 沒有展開。有些介紹把它寫成「新內容郵件通知」，這個說法可能對、可能不完整，建議當成「有郵件寄送能力」來理解，具體觸發邏輯待確認。

資料安全與隱私同樣缺乏細節。README 有一段 Security Best Practices，列了七條建議：改資料庫預設密碼、用強隨機的 JWT secret、透過反向代理開 HTTPS、限制對外暴露的 port、保持映像與依賴更新、不要把 .env 提交進版本控制、設定資料庫自動備份。這些是部署端的自主管理建議，不是 Readdig 本身的內建安全機制。它沒有提到資料加密靜態儲存、使用者密碼雜湊方式、或 GDPR 相關的資料處理說明。

營運主體的部分也要先認清。Readdig 的 GitHub 帳號是 readdig，README 的 support 連結指向一個 Buy Me a Coffee 頁面（buymeacoffee.com/debugging），開發者代號是 debugging。沒有公司全稱、沒有聯絡地址、沒有正式的支援管道。這在開源專案裡很常見，但如果你打算把企業的訂閱源交給它，這個「一個人維護」的現實要先接受。

怎麼判斷它適不適合你

把 repo 能核對的事攤開之後，判斷的起點其實很具體。

如果你已經在用 Feedly 或 Inoreader 這類託管服務，而且沒有特別不滿，Readdig 對你的價值會落在「資料自主」與「想把 Podcast 與 RSS 收在同一個 app」這兩件事。它的 PWA 能安裝、OPML 能搬遷、Apache-2.0 授權寬鬆，搬過來的門檻不高；但你得自己扛 PostgreSQL、Redis、Docker 這套基礎設施的維護，也要接受一個人維護的專案在長期穩定保證上本來就比較弱。

如果你本來就在自架服務，手上已經有 Docker 環境與一台閒置的 VM，Readdig 是一個部署成本相對低的選項：拉 GHCR 映像、改 docker-compose、打 /health 確認就上線。它的社群聚合能力（V2EX、Hacker News）是跟其他自架閱讀器比較時的差異點，如果你本來就活躍在這些平台，把討論串跟文章收在一起會省下切換成本。

如果你要的是「裝了就能用、不用管伺服器」的託管型閱讀器，readdig.com 上其實已經有一個開發者自己經營的託管版，首頁提供註冊與試用入口。不過它的定價、方案差異、免費額度都沒有在首頁公開，得註冊進去才看得到；再加上營運主體是單一開發者而非公司，能不能長期依賴要自己衡量。託管版適合想先試水溫、確認介面順不順手再決定要不要自架的人；但如果你很在意資料放在別人伺服器上，自架 Apache-2.0 版本會是更穩的歸宿。

最後提醒一個實務動作：部署前先進 repo 把 docker-compose.example.yml、README 的環境變數表、app/package.json 這三份各自看一次，確認技術棧與你手上的環境相容。Readdig 的 repo 更新頻率很高（6 月一週內推了 16 個版本），部署時記得拉當下最新版，本文提到的 v1.3.16 可能已有調整。