OtterHub 開源 Serverless 私人雲端：用 Cloudflare 加 Telegram 拼出的檔案存儲，能當 Google Drive 嗎

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

想把幾份設計素材、錄音檔、臨時簡報找個地方放，又不想每年花幾千塊養一台 VPS，這是 OtterHub 想解決的那種小痛點。它用 Cloudflare Pages 跑網頁、用 Cloudflare KV 存檔案清單，再把你上傳的檔案本體丟進 Telegram 機器人，拼出一個看起來像雲端硬碟的介面。整套服務不用自己架伺服器，原作者 DJChanahCJD 把它定位成「給個人用的私人雲端硬碟」，目前在 GitHub 上以 MIT 授權公開，主分支以 TypeScript 撰寫，前端是 Next.js、後端是跑在 Cloudflare Pages Functions 上的 Hono。

這篇文章要把 OtterHub 放回它真正的位置：它是一個架構漂亮的 Serverless 實驗，不是 Google Drive 的免費替代品。把它當主力雲端之前，有幾件事得先講清楚。

Pin

把檔案交給 Telegram 機器人，意味著什麼

OtterHub 的核心是把「檔案存哪」這件事外包給 Telegram。你透過瀏覽器上傳，前端把檔案切成每片不超過 20MB 的分片，經由 Cloudflare Pages Function 呼叫 Telegram Bot API，把分片送進機器人所在的聊天室，再把 Telegram 回傳的 file_id 寫進 Cloudflare KV。下載時走相反路徑：從 KV 讀出 file_id，再向 Telegram 串流拉回分片，支援 HTTP Range 讓影片可以拖進度條。

這套流程運作起來很順，但「檔案存在 Telegram」這件事自帶一組你不會在官網首頁看到的成本。Telegram 不是設計來給你當無限雲端。Bot API 對單一檔案有 20MB 上限，自架 Bot API server 可放寬到 2GB，把機器人當倉庫大量堆檔，碰到平台風控、頻道或帳號被限制的案例在開發者社群裡時有所聞。檔案本體握在別人的服務條款手裡，這是 OtterHub 與生俱來的脆弱。

更少被討論的是檔案在 Telegram 伺服器上不是端對端加密。OtterHub 存的是 Telegram 回傳的 file_id，等於一把能直接取回原檔的鑰匙；誰能拿到這把鑰匙、誰能看到檔案內容，取決於 Telegram 的伺服器政策與你的 Bot Token 安全。真正重視機密的檔案傳遞，仍然應該走端對端加密的管道，而不是寄望 Telegram Bot API 當後端。Bot Token 一旦外洩，等於你的整套私人雲端的鑰匙同時掉了出去。

再往上一層看，這個方案的「免費」是建立在 Cloudflare 與 Telegram 兩家都維持現行額度的前提上。README 自己點出 Cloudflare KV 免費版總容量 1GB、Workers 與 Pages Functions 有 CPU 與執行時間限制，並明確建議不要並發上傳多個大檔。任何一家調整免費額度、改變 Bot API 規則，或你的帳號被風控，整套私人雲端就可能瞬間失效。把它當主力唯一副本，風險結構和買一台實體硬碟完全不同。

分片上傳與串流預覽：技術上確實做對了

把風險講完了，也得公平講它技術上做對的事。OtterHub 比起把檔案丟給機器人就完事的「發圖機器人」，多解了兩個硬問題。

其中最關鍵的是大檔分片。它在前端把檔案切成每片不超過 20MB、逐片上傳 Telegram，再用 waitUntil 非步處理，最終把所有 file_id 合併寫進同一筆 KV 紀錄。整個流程拆成四步：初始化時建立最終 KV 並回傳唯一 key、分片逐個送進臨時 KV（TTL 一小時、單片 value 上限 25MB）、waitUntil 把分片非步推上 Telegram 取得 file_id、合併完成後把 file_id 寫進 chunks 陣列並清掉臨時 KV。README 寫實測穩定上傳 100MB、理論上限 1GB（即 50 片乘以 20MB）。這個數字是 README 自己給的，實際表現取決於你的網路與 Cloudflare 當下的額度，不要把它當保證值。

配套的是HTTP Range 串流。下載時它從 KV 讀出分片順序，向 Telegram 串流拉取並邊拉邊回給瀏覽器，支援 Range 請求，所以影片可以像正規影音站那樣拖進度條、按需載入，不必等整檔下載完。為了避免 Range 請求干擾 Cloudflare 快取、造成快取內容不一致，作者還把非 Range 請求走 Cache、Range 請求直出分開處理。這是「做一個像樣的檔案管理器」會踩到的細節，OtterHub 處理得不馬虎。

其他能力包括密碼登入（JWT 加 Cookie）、30 天回收站（到期自動清除、支援復原與永久刪除）、基於 nsfw.js 的客戶端圖片遮罩、檔案收藏與標籤、批次下載與重命名、按標籤或日期篩選，以及可選的 Workers AI 圖片自動描述。nsfw.js 的遮罩是純客戶端推斷，跟內容審查或雲端偵測無關，別誤以為它能取代任何正式的內容過濾。

README 還提到一個加分配件：把機器人加入 Telegram 頻道或群組、設定 Webhook 後，在頻道裡發送不超過 20MB 的檔案會自動匯入 OtterHub，並回覆一個直鏈。頻道匯入有 20MB 上限，超過的大檔還是得走網頁端的分片流程。

Pin

跟 AList、Cloudflare 圖床的差別在哪

Pin

TechMoon 先前介紹過的 AList 走的是另一條路：你自己架一台伺服器，把 OneDrive、Google Drive、阿里雲盤等各家雲端的 Token 收攏進同一個網頁介面，檔案本體仍在你原本的雲端帳號，AList 只做 302 轉發與索引。OtterHub 不碰你既有的雲端帳號，它直接把 Telegram 當倉庫、把 Cloudflare 當介面，連一台 VPS 都不用租。

兩者放在同一張表上看會更清楚：

OtterHub 與 Cloudflare 圖床專案（例如 Telegraph-Image、CloudFlare-ImgBed）底層是類似的「CF 加 Telegram」組合，但定位不同：圖床專案偏向公開貼圖與輕量分享，OtterHub 強調私人訪問控制與全格式檔案管理。差異是真實的，但都不改變「檔案最終落在第三方平台上」這個共同前提。

把 OtterHub 與 AList 擺在一起看，會看到兩種截然不同的「自託管」哲學。AList 要你出機器、出時間維護，換來的是對介面與 Token 的完全主控；OtterHub 把維運全部丟給雲服務，換來的是零成本但也零主控，哪天平台改規則你只能跟著走。選哪一邊，取決於你願意為「主控權」付出多少維運成本。

把「免費無限」這四個字拆開來看

很多介紹文會把「Telegram 提供無限免費雲端」當成這類方案的最大賣點。這個說法技術上不算錯，但落地到 OtterHub 這種「拿 Bot API 當儲存後端」的用法時，得自己補上幾條但書。Telegram 官方對一般使用者提供的雲端聊天備份確實沒有明確容量上限，但 Bot API 是設計來讓機器人收發訊息的，並不是公開承諾給第三方應用當無限物件存儲使用。把機器人當檔案倉庫、長期堆大量檔案，等於把一個通訊介面挪用為儲存介面，這種挪用能撐多久，取決於平台容忍度，而不是合約保障。

Cloudflare 那邊的「免費」也一樣得看細節，沒有任何一家雲服務的免費方案是無條件永久承諾。Pages Functions 免費版有每日十萬次請求、單次 CPU 時間上限，KV 免費版有每日十萬次讀取、一千次寫入、1GB 儲存。對一個人低頻使用綽綽有餘，但任何形式的熱門分享連結、多人同時下載、批次縮圖產生，都會快速吃掉額度。README 明確建議不要並發上傳多個大檔，正是因為分片流程會密集消耗 CPU 與 KV 寫入。把這兩家湊在一起，OtterHub 換到的是「在免費額度內的低頻個人使用」這個相當具體的甜蜜點，不是「無限免費雲端」這個聽起來美好、實際上經不起追問的童話。

KV 容量換算：能塞多少檔案

關於「到底能存多少」，README 給了一組值得拆開來看的數字。Cloudflare KV 免費版總容量 1GB，OtterHub 每筆檔案在中繼資料層佔用不到 500 bytes（包含 key、檔名、大小、上傳時間、分片資訊），作者用 1GB 除以 500 bytes 推出「理論上可存超過 200 萬筆檔案」。這個數字看起來很大，但要記得幾件事。

第一，這 200 萬指的是「檔案清單筆數」，不是「檔案本體容量」。檔案本體是塞在 Telegram 那邊的，Telegram 對 Bot 並沒有公開的長期儲存總量上限，但這也意味著你無從查驗到底存了多少、何時會被清理。第二，KV 的 1GB 是免費版上限，超過要進付費方案。第三，檔案數量一多，KV 讀取次數（免費版每日十萬次讀取）也會成為瓶頸，特別是批次列表或搜尋場景。把「200 萬筆」當作架構理論值來理解就好，實際會卡在前面這幾道軟上限。

中國大陸讀者的硬門檻

README 沒有特別強調，但對台灣與海外讀者影響不大、對中國大陸讀者卻是繞不過去的一點：Telegram 在中國大陸需要翻牆才能存取。由於 OtterHub 的檔案本體與 Webhook 上傳機制都依賴 Telegram API，這套方案在中國大陸的使用門檻比海外高得多，部署成功不代表日常上傳下載會順暢。這不是 OtterHub 的問題，而是它選擇的技術堆疊自帶的地理限制。

部署流程長什麼樣

實際部署 OtterHub 的步驟不算難，但要對 Cloudflare 與 Telegram 兩個平台都熟悉。把流程走一遍，也能順便看清它的依賴究竟有多深。

前置條件是 Node.js 18 以上、一個 Cloudflare 帳號、以及一個 Telegram Bot Token。Token 透過 Telegram 內的 @BotFather 建立，Chat ID 則可以請 @userinfobot 回覆取得。這組 Token 與 Chat ID 會以環境變數 TG_BOT_TOKEN、TG_CHAT_ID 的形式設進 Cloudflare Pages，等於把通往你檔案倉庫的鑰匙交給 Cloudflare 託管。

正式部署的順序是：Fork 專案、在 Cloudflare Dashboard 建立 Pages 專案、設定建構命令 npm install && npm run build 與輸出目錄 frontend/out、填入密碼與 Telegram 環境變數、建立並綁定名為 oh_file_url 的 KV 命名空間、可選擇綁定 Workers AI、最後重新部署讓變數與綁定生效。整個流程不需要碰任何伺服器，全部在 Cloudflare 後台完成。

本地開發更簡單，npm install 加 npm run dev 就能跑，開發環境預設密碼 123456、儲存改用本地 R2 不必接 Telegram。作者用 Husky 加 lint-staged 在 commit 前跑 Prettier 與 typecheck、push 前跑 build 與 ci-test，看得出這是一個有在認真維護的專案，不是丟上來就放生的玩具。最近的 commit 紀錄裡還能看到主題切換修復、行動端批次下載、預覽書籤持久化這類細節打磨，專案本身是活的。

不過部署簡單，不等於長期維運省心。你要持續追蹤兩件事：一是上游 Cloudflare 與 Telegram 任何 API 或額度調整，二是 OtterHub 本身的更新。原作者目前活躍，但這類個人專案沒有商業支撐，一旦作者停更、Telegram 改了 Bot API 行為，你得自己 fork 出來接手維護。把這個隱形工時算進「零伺服器成本」的代價裡，比較接近真實。

常見問題與官方自己的回答

README 的 FAQ 段落誠實度頗高，值得直接引用幾條。第一條：上傳完立刻看為什麼檔案不完整？因為分片走 waitUntil 非步處理，分片還沒全部到齊前檔案會暫時不完整，重新整理通常就好。第二條：Telegram 20MB 限制怎麼突破？答案就是前面講的分片加串流合併。第三條：Cloudflare Workers 免費版夠用嗎？作者自己回答「個人場景通常足夠」，但「不建議並發上傳多個大檔」，並把官方 limits 文件連結放在底下，要讀者自己去看。

這幾條 FAQ 透露的訊息一致：OtterHub 是給「一個人、低並發、非關鍵資料」的場景設計的。把它推到多人共用、高並發、商業資料的場景，免費額度的天花板很快就會碰到。

適合誰，不適合誰

會想在 OtterHub 上花時間的，是手邊有閒置 Cloudflare 帳號、平常就重度使用 Telegram、想要一個看得見介面又不願租伺服器的人。把過往幾份設計草稿、部落格素材、臨時錄音檔丟進去當備份，享受「自己拼出一台雲端」的樂趣，這是它最舒服的使用情境。

不適合的也很明確：不要把唯一、不可複製的商業資料交給它。README 的免責聲明自己寫得很誠實，這是一個 Serverless 架構學習案例，高度依賴兩家第三方 API，不建議用來存機密或高價值商業資料。需要「穩定存十年、幾十 GB 隨取隨用」的生產力工具，老實買一顆實體硬碟、或訂閱 正規商業雲端，會比靠 Telegram 當後端穩得多。

OtterHub 最值得借鏡的不是它的功能，而是它的架構選擇：用分片與 Range 請求把第三方 API 的限制撐到極限、把狀態最小化塞進 KV、讓整套服務零伺服器成本跑起來。把它當成「Serverless 拼裝典範」來讀，會比把它當「Google Drive 殺手」來用更接近它真實的樣貌。如果你正好屬於「會翻牆、用 Telegram、有 Cloudflare 帳號、想玩架構」的那群人，它會是一個讓你學到不少東西的週末專案；如果你只是單純想找個地方備份重要資料，回頭看一眼 AList、或直接訂一個商業雲端，會是更穩的選擇。