CattoPic 開源圖床自架解析：自動轉檔綁 Cloudflare Images，成本與授權先看清楚

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把圖床搬上 Cloudflare 全家桶，聽起來是裝完就零成本的漂亮主意。CattoPic 就是這個思路的開源實作：前端 Next.js、後端 Cloudflare Workers、圖檔進 R2、中繼資料進 D1，四項服務拼出一套自架圖床。會想自己架圖床，通常是因為託管圖床開始限制外連、改變流量政策，或者單純不想把圖檔放在別人手裡，碰上服務收掉就全部失效。CattoPic 把這些顧慮用「搬進自己 Cloudflare 帳號」來回答，聽起來漂亮，但把它的設定檔與上傳原始碼讀過一遍，主打的自動轉檔其實綁死另一項獨立計費產品 Cloudflare Images，不在 R2 與 D1 的免費額度裡。

Pin

結論先講。CattoPic 適合已經在 Cloudflare 生態付費、想把圖床收進自己帳號的開發者；如果你打的是純免費主意，帳單會在轉檔與儲存兩處先冒出來。它把資料主權還給你，但代價不是零。

它實際吃掉哪些 Cloudflare 服務

從 wrangler.example.toml 的綁定清單看，CattoPic 一次要用到五項 Cloudflare 服務，不是「一支 Worker 搞定」的那種輕量：

• Cloudflare R2 存原始圖與轉檔後的版本
• Cloudflare D1（SQLite）放圖檔中繼資料、標籤、API 金鑰
• Cloudflare KV 做回應快取
• Cloudflare Images 做格式轉換與壓縮
• Cron Triggers 每小時清一次過期圖

這還沒算前端要另外部署到 Vercel，以及選用的 Cloudflare Queues。換句話說，它把「自架」定義成「搬進你自己的 Cloudflare 帳號」，而不是傳統那種開一台 VPS 跑 Chevereto 或 Lychee 的單機邏輯。同樣把 Cloudflare 當作底層的設計，也能在 movecar 這類 Worker 小工具身上看到，差別在於圖床牽的服務更多、儲存與轉檔兩條成本線更明顯。

主打轉檔為何綁付費產品

CattoPic 最常被提起的賣點是上傳後自動產生 WebP 與 AVIF 版本，降低傳輸頻寬。這件事在原始碼裡有明確對應：worker/src/handlers/upload.ts 裡寫死兩個常數，MAX_FILE_SIZE 是 70MB，註解標示為 Cloudflare Images Binding 的上限；CLOUDFLARE_IMAGES_MAX_BYTES 是 10MB，超過就改走 Transform URL 路徑。wrangler.toml 也透過 [images] binding = "IMAGES" 把轉檔能力掛進 Worker。

兩條路徑的差別在於，10MB 以下的圖走 Images binding 即時轉換並把成品寫進 R2，超過 10MB 則改用 Transform URL 在請求時動態變換，儲存與計費邏輯不同，對大尺寸攝影作品或印刷原圖來說是會踩到的分支。

要點在於 Cloudflare Images 是獨立計費的產品線，與 R2、D1 的免費額度分開計算。實際費率、是否隨方案附送變換額度，以 Cloudflare 官方方案頁為準，這裡不釘死具體數字，因為會隨方案與時間漂移。結構性的事實才是重點：自動轉檔這個主打功能，落在「免費額度」這個故事之外。如果你只看到 R2 與 D1 都有免費額度就認定整套圖床零成本，那是最容易踩到的認知落差。

具體來說，部署前先進 Cloudflare 後台確認你的方案有沒有附帶 Images 變換額度、超出後怎麼計價，再把這筆費用和 R2 的儲存與作業量一起算進總成本，才不會上線後才發現帳單分成好幾條。

每張圖最多存三份，儲存額度跑得比你想的快

schema.sql 的 images 表把這件事說得很白：每筆圖檔紀錄有 path_original、path_webp、path_avif 三個欄位，分別指向 R2 裡的實體檔案。每張圖在 R2 裡最多留存三份檔案（原圖、WebP、AVIF），但 WebP 與 AVIF 是壓縮版本，實際佔用通常小於原圖；若原始檔本身已是 WebP、AVIF 或 GIF，程式會跳過轉檔只存一份。而 R2 標準儲存的免費額度只有 10 GB-month，原圖與轉檔版本全部一起計入同一個額度，不是分開算。

對上傳量大的使用者，這條儲存成本線很快就會碰到付費門檻。CattoPic 也提供 expiry 機制與 Cron 每小時清過期圖，算是對儲存壓力的內建調節，但它不會幫你決定該不該開啟自動轉檔，那是部署者要自己算的帳。這種「架構漂亮、但實際帳單要自己拆」的特質，在 EdgeEver 這類 Cloudflare Serverless 自架專案上也看得到，差別在於筆記庫的儲存膨脹通常比圖床慢一個量級。

授權是 GPL-3.0，修改就要跟著開源

LICENSE 檔是 GNU General Public License 第三版。這是強制傳染型的授權，重點不是能不能商用，而是你一旦修改並對外發布，整個衍生作品都必須以相同授權開源，並保留原始版權聲明。對單純自用、不對外發布的人影響不大；對想把 CattoPic 改一改塞進自家商業產品的人，這條是硬門檻。

一個常見的疑問是，只是把 CattoPic 架起來自己用、不對外發布修改版，會不會觸發授權義務。答案是純自架自用不會，GPL 的開源義務只在對外傳遞衍生作品時啟動，單純架成網路服務讓自己或訪客透過瀏覽器使用，本身不會觸發。CattoPic 選的是 GPL 而不是 AGPL，所以也不會像 AGPL 那樣因為別人透過網路使用你的服務就強制開源，這點對想把 CattoPic 包成對外服務的人相對友善；但一旦你修改程式碼並對外發布安裝包或原始碼，GPL 的傳染條款就會啟動。

這條與功能無關，但會直接改變你能不能採用它。許多圖床工具選 Apache 或 MIT 之類寬鬆授權，CattoPic 選 GPL-3.0，等於把「你能改但要回饋」寫進合約。是否接受，取決於你的商業模式與其是否相容。

幾個會卡人的硬限制

部署前先確認這幾個硬限制，避免到一半才卡住：

• 單檔上限 70MB，超過會回 413，這是 Cloudflare Images Binding 的硬上限
• 轉檔單圖 10MB 以上會 fallback 到 Transform URL，流程不同
• 前端需要 Node.js 24 以上，README 前置需求載明
• 非同步刪除佇列是選用，啟用 Cloudflare Queues 需要 Workers 付費方案
• 隨機圖 API 是公開端點，不需要金鑰，其餘上傳與管理端點都要 Bearer API 金鑰

API 金鑰存在 D1 的 api_keys 表，部署時手動 INSERT，而不是 Worker 環境變數；部署文件也提醒不要把金鑰設成 Worker secret，D1 才是唯一來源。這個設計把金鑰與 Worker 程式碼分離，但同時代表金鑰的安全等於你 D1 資料庫的安全。

Pin

隨機圖 API 與單一金鑰：能公開到什麼程度

隨機圖 API 是 CattoPic 唯一不需要金鑰的公開端點，設計上就是給人嵌進網頁用的。它支援四個過濾參數：orientation 指定橫向或直向、tags 用逗號分隔做多標籤交集篩選、exclude 排除特定標籤、format 指定回傳原圖或 WebP 或 AVIF。實際用途是隨機展示圖、社群封面、部落格隨機首圖這類情境，只要有人知道你的 Worker 網址，就能拉到符合標籤的隨機圖。舉例來說，想要一直換的橫向風景封面，可以把 orientation 設成 landscape、tags 指定風景主標籤，再把不想曝光的草圖用 exclude 標籤擋掉，API 就只會在符合條件的圖庫裡隨機取一張。

這件事要和它的金鑰模型一起看。CattoPic 的 api_keys 表是單一金鑰邏輯，一組 Bearer 金鑰就解鎖所有受保護端點，涵蓋上傳、列表、更新、刪除，以及標籤的增改刪。它沒有使用者帳號系統，沒有角色權限，沒有每使用者流量配額。換句話說，CattoPic 是為單一管理者設計的圖床，不是多租戶的圖片服務。如果你需要團隊帳號或每人額度，這一層得自己疊上去。

公開隨機圖 API 也意味著你想保密的圖，必須靠標籤排除機制擋掉，不能假設它預設不曝光。把不公開的圖綁上專用標籤，再用 exclude 過濾，是這套架構下唯一能讓隨機池不抓到它們的做法。這個邊界要部署者自己顧，CattoPic 不會替你判斷哪張圖該不該公開。

部署路徑：手動還是 GitHub Actions

README 給兩條部署路線。一條是手動跑 wrangler deploy，一條是用 GitHub Actions。對 fork 用戶，README 明確建議走 Actions，原因是同步上游更新時不會覆蓋你自己的 wrangler.toml，設定內容放進 WRANGLER_TOML 這個 secret。如果你打算長期跟著上游更新，從第一天就選 Actions 比較省事，事後再從手動遷移過去會多一道工。這條選擇與功能無關，但會影響你未來收更新的順手程度。

升級流程也值得先看一眼。schema.sql 是新安裝的基線，舊部署保留原本的 D1 就好；新版加入的 deletion_jobs 表會在第一次需要時由 Worker 透過 D1 binding 自動建立，不必手動跑 migration。API 金鑰同樣不必輪換，繼續留在 api_keys 表。對已經部署的人來說，升級負擔比想像中輕，這點 README 處理得算清楚。

另外要記得 CattoPic 是兩段式部署：前端 Next.js 部署到 Vercel 或任何靜態主機，後端 Worker 部署到 Cloudflare，兩邊各自獨立。前端要設 NEXT_PUBLIC_API_URL 指向 Worker 網址，還要設 NEXT_PUBLIC_REMOTE_PATTERNS 讓 Next.js 的圖片元件接受 R2 的網域，否則圖片不會顯示。這代表你得同時顧兩個平台的環境變數，不是一個指令就把整套服務推上去。

跟傳統圖床的差異

CattoPic 不是要取代 imgBB 或 Chevereto 那類方案，定位不同。imgBB 走託管路線，你把圖傳上去就不管底層，代價是圖檔放在別人伺服器，額度與政策由對方決定。Chevereto 與 Lychee 走單機自架，你開一台 VPS、裝好就跑，自由度高但機器、頻寬、SSL 憑證都要自己顧，流量爆掉時直接吃主機資源。CattoPic 走的是 serverless 自架，你把整套搬進 Cloudflare 帳號，好處是不用顧機器、邊緣節點近、流量尖峰靠 Cloudflare 吸收，代價是綁定 Cloudflare 的計費與服務邊界，搬家成本也跟著上升。三者本質上是在選你願意把成本與控制權放在哪一層。

同樣是「本地優先、自己架」的思路，CookHero 把這套架構用在食譜管理 Agent上，差別在 CookHero 的外送壓力落在 LLM 與第三方 API，CattoPic 的外送壓力落在儲存與轉檔。選哪一種，本質上是在選你願意把成本與依賴放在哪一層。

Cloudflare 付費用戶才適合，三種情況請先跳過

CattoPic 適合已經在用 Cloudflare 付費方案、想把圖床資料主權收進自己帳號、並能接受 GPL-3.0 授權義務的開發者。它把圖檔、金鑰、中繼資料都留在你的 Cloudflare 租戶裡，這點是真的，也確實比託管圖床多一層主控權。

它不適合三種情況：

• 打純免費主意、沒打算在任何一層付費的人，轉檔與儲存兩條線會先撞牆。
• 想把圖床修改後包進閉源商業產品的人，GPL-3.0 不允許。
• 需要穩定搬遷、不想被綁在單一 serverless 平台的人，五項綁定都指向 Cloudflare，離開要重寫不少層。

換個角度看，CattoPic 真正打中的是「想要一個有程式化介面、又能自己管資料」的單人開發者。隨機圖 API 加上單一金鑰的設計，讓它可以被當成部落格、社群機器人或前端 demo 的圖源來呼叫，而不用先架一整套多媒體資產管理系統。這個定位比「免費圖床」更精確，也比較不會在帳單出現時感到意外。

CattoPic 的工程品質與架構清晰度是看得出來的，原始碼結構、升級流程、GitHub Actions 部署選項都到位。它真正的問題不在能不能用，而在你打算把「自架」理解成零成本，還是理解成把帳單與依賴從 VPS 搬到 Cloudflare。把它當後者來評估，這套圖床值得認真看；把它當前者，帳單會替你回答。