microfeed：在 Cloudflare Workers 上執行的以 Feed 為中心的 CMS
專案速覽：在 cloudflare 上自架的輕量級 cms，用於播客、部落格、照片、影片、文件和精選 URL。
秒懂
- 它是什麼？
- microfeed 如何使用 Cloudflare Workers、R2 和 D1，透過單一管理 CLI 發佈網頁、RSS 和 JSON Feed。
- 適合誰用？
- microfeed 是一個面向 Cloudflare 的 CMS，用於以 Feed 為基礎的內容，透過 yarn manage 管理，並可選擇由 AI 編碼代理部署。它處於開放 alpha 階段，支援多個實例和預覽，並以 AGPL-3.0 授權。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月17日）與我們的分析，不構成法律意見。
開源專案深度解析
以 Feed 為導向的 Cloudflare Workers CMS：1
microfeed 是一個輕量級內容管理系統，執行在 Cloudflare 的 Workers、R2 和 D1 上，由 Listen Notes 建置。它面向那些希望將音訊、影片、照片、文件、部落格文章和外部 URL 發佈為網站、RSS Feed 或 JSON Feed，而無需自行執行伺服器的人。README 將其描述為開放 alpha 專案，並說明 Cloudflare 是第一個支援的平台；它沒有提到任何其他託管供應商或穩定版本。
實際部署 microfeed 可從 `npx @microfeed/cli manage` 開始，確認 Node.js 22.12 或更新版本、Cloudflare 綁定與部署結果；手動路徑則核對 `yarn manage accounts`、`yarn manage init`。發佈後檢查 `/admin/`、網站、RSS、JSON Feed 與 `api/v1/openapi.json`，並用 `yarn manage snapshot create` 和 `snapshot pull` 驗證 D1 schema、R2 中繼資料及 checksum 是否齊全。`yarn manage destroy --dry-run` 的站點名稱確認和 `--keep-data` 應在刪除前演練。AGPL-3.0 對網路服務修改版提供原始碼的要求，會影響自訂主題與營運方式。
本章的核對焦點是 microfeed-microfeed 第 1 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 1 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
Feed 模型涵蓋的內容：2
README 將概念追溯到 1990 年代以來構成網路重要部分的網路 Feed。microfeed 將 Cloudflare 部署變成一個 Feed，可以表現為播客、部落格、圖片庫、影片頻道、個人網站、精選連結清單、行銷網站、帶 GUI 和公共 JSON 端點的無頭 CMS、域名銷售清單、書籍網站或變更日誌。列出的範例包括 llamacorn.listennotes.com 和 microfeed.org。具體輸出取決於你發佈的內容和你新增的自訂程式碼。
本章的核對焦點是 microfeed-microfeed 第 2 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 2 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
兩條安裝路徑，同一個底層 CLI：3
安裝需要本地 Git 儲存庫副本。README 建議的方式是在 AI 編碼代理（如 OpenAI Codex、Claude Code 或 Cursor）中開啟該副本，並傳送提示 'Deploy microfeed to Cloudflare.'。代理使用儲存庫的 deploy-microfeed 技能，並執行與人工執行相同的 yarn manage 命令。手動路徑是安裝 Git 和 Node.js 24，啟用 Corepack，執行 yarn install，然後執行 yarn manage accounts 和 yarn manage init。README 明確排除了 Cloudflare 儲存庫匯入、Workers Builds、部署按鈕、GitHub Actions 和使用者建立的 API 權杖作為部署方法。
本章的核對焦點是 microfeed-microfeed 第 3 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 3 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
多實例、預覽與安全移除：4
一個本地 Git 副本可以管理多個獨立的 microfeed 實例。僅限本地的實例在你的電腦上執行，使用模擬的 D1 和可選的 R2；Cloudflare 實例儲存在儲存庫中，可以從中部署或管理。CLI 支援 yarn manage connect 以附加現有相容 Worker 而不更改它，以及 yarn manage instances 和 use 來列出和選擇。預覽部署建立一個單獨的 Worker 和 D1 資料庫，同時重用生產 R2 儲存桶，將生產媒體儲存在 production/ 下，預覽媒體儲存在 preview/ 下。對於移除，yarn manage destroy 需要 dry-run 計畫和精確的站點名稱確認；--keep-data 保留資料庫和媒體儲存桶。README 沒有說明推薦多少個實例或任何效能限制。
本章的核對焦點是 microfeed-microfeed 第 4 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 4 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
儀表板保護與內容發佈：5
管理儀表板受內建電子郵件和密碼登入保護，預設位址是 /admin/。初始化期間你可以設定它或跳過它，這會使儀表板公開，直到你新增 Cloudflare Zero Trust Access。後續更改使用 yarn manage auth setup、reset-password、change-email、change-path 或 disable。一次性密碼連結在 30 分鐘後過期。發佈透過儀表板進行：你可以建立、編輯和刪除文章，在啟用 R2 時上傳媒體，或在僅內容模式中使用外部 URL。外觀自訂透過編輯 Settings / Custom code 中的原始 HTML 和 CSS 完成，使用 mustache.js 範本，變數來自 Feed Json 或 Item Json。這也讓你可以將實例用作無頭 CMS。
本章的核對焦點是 microfeed-microfeed 第 5 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 5 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
追蹤、備份與授權：6
對於下載追蹤，README 描述了 Settings / Tracking URLs 中的追蹤 URL 功能，該功能將第三方 URL（如 OP3 或 Podtrac）前置到媒體檔案連結。備份由 yarn manage snapshot create 和 snapshot pull 處理，產生包含 D1 schema 和資料、遷移歷史、R2 儲存桶、物件中繼資料和總和檢查碼的可讀歸檔。歸檔未加密且以僅擁有者權限建立，因此 README 建議你自己加密。該專案根據 AGPL-3.0 授權；授權摘錄稱它是一個為網路伺服器軟體設計的 copyleft 授權，要求修改版營運商向使用者提供原始碼。README 不包括安全保證、支援承諾或生產效能資料。
本章的核對焦點是 microfeed-microfeed 第 6 個實作面向：將命令、檔案或設定鍵放進測試紀錄，並把 README 已說明的能力與尚未說明的部分分開。這樣閱讀結果才會對應到實際專案，而不是把一般工具的期待套在它身上。針對第 6 章，還要把輸入條件、執行結果與限制逐項寫下，尤其是 microfeed-microfeed 沒有承諾的功能，不應由標題或社群印象代替。這段專案分析也要交代環境、資料流、錯誤處理、版本差異和權限邊界，讓讀者能以同一組步驟重現觀察。採用者還應檢查安裝依賴是否與現有環境衝突，確認資料放在哪裡、誰能讀寫、失敗時如何回復，以及升級後設定是否仍然有效。若專案提供多種入口，就逐一比較它們的輸入格式、權限需求、輸出位置與日誌內容。這些細節比單純列出功能名稱更能說明 microfeed-microfeed 是否符合目標工作流，也能避免把作者的自報能力誤當成已經在目標環境證實的結果。
編輯結論
microfeed 是一個面向 Cloudflare 的 CMS，用於以 Feed 為基礎的內容，透過 yarn manage 管理，並可選擇由 AI 編碼代理部署。它處於開放 alpha 階段，支援多個實例和預覽，並以 AGPL-3.0 授權。README 沒有提供使用者數量、正常運行時間、安全稽核或其他雲端平台的相容性。 對 microfeed-microfeed 而言，適合先在隔離環境由熟悉相關技術的團隊試用；不適合把 README 未承諾的能力當成保證。先依專案文件執行具體命令，檢查輸入、輸出、日誌、權限與重新啟動後的狀態，再決定是否擴大使用。
社群筆記