📦 Karakeep 深度開箱：AI 幫你整理書籤的猛獸，還是燒光你 OpenAI 額度的隱形怪物？
🔥 懶人包：
Karakeep（前身叫 Hoarder，因商標糾紛改名）是開源界野心最大的「全端書籤典藏系統」——不只存網址，還能存筆記、圖片、PDF，AI 自動打標籤、全文搜尋、影片下載、OCR 通通有，GitHub 已累積超過 27,400 顆星星。但它同時也是一頭吃資源的猛獸：官方建議至少 2GB RAM，曾爆發 SSRF 與儲存型 XSS 兩個高風險 CVE，AGPL 授權對商業二次開發極不友善，而且如果你把 OpenAI API Key 接上去一次匯入兩萬筆舊書籤，荷包可能一晚失血上百美金。適合有 Docker 基礎、重視資料主權的自架玩家，不適合想在企業內網無腦亂丟機密文件的公司 😱
[2]
內容目錄
📌 Karakeep 到底是什麼？先搞懂它從哪裡來
你是不是也這樣？瀏覽器裡塞了幾百個書籤，資料夾名稱寫著「稍後閱讀」「稍後閱讀 2」，但從頭到尾沒有一次真的點開看過。存書籤變成一種「假裝自己處理過這件事」的心理安慰，實際上早就變成一座無人聞問的數位垃圾場 🗑️
Karakeep 就是為了解決這個「書籤破產」的窘境而生。開發者 Mohamed Bassem 是一位擁有七年經驗的系統工程師，眼看知名稍後閱讀服務 Pocket 逐漸式微，甚至面臨關閉危機，加上自己本來就熱愛在家裡搞 Homelab 自架伺服器，於是動手打造了這套能把資料主權完全掌握在自己手裡的替代方案 ✨
專案原本叫做 Hoarder，直到 2025 年初才正式更名為 Karakeep。名字來自阿拉伯語「كراكيب（Karakeeb）」，是個口語詞彙，用來形容那些看似雜亂無章、卻往往藏著個人回憶或隱藏實用價值的雜物——這個命名巧思本身就精準點出了這款工具的定位 💡
一般瀏覽器書籤只是把東西「隨手丟進儲藏室」，久了根本找不到。Karakeep 則像是把你丟進去的每一樣東西（網頁、圖片、影片、PDF）都先拍照存證、抽真空封膜、貼上 AI 自動生成的標籤，再依照類別整齊上架。等你哪天想找「去年那份鬆餅食譜」，只要在搜尋框打「鬆餅」兩個字，系統就能從幾千筆存檔的內文裡，毫秒級精準撈出目標，不用再一格一格資料夾去挖 🔍
截至文章撰寫時，Karakeep 在 GitHub 上已經累積超過 29,000 顆星星、超過 1,300 個 Fork，並吸引了超過 150 位開源貢獻者參與維護，最新穩定版本為 v0.33.2（2026 年 5 月 8 日釋出）✅
但這裡要先幫大家打預防針：Karakeep 絕對不只是一個存網址的書籤管理器，它是一套高度整合的「全端數位典藏系統」，底層導入了大型語言模型自動標籤、內建無頭瀏覽器抓取網頁完整快照。這種無差別抓取行為，讓它在實際使用時很容易跟各大內容平台的服務條款起衝突——GitHub 的 Issue 追蹤區已經明確記錄了 Reddit 開始針對 Karakeep 的爬蟲進行阻擋 ⚠️
🚀 官方主打功能，實際表現究竟如何？
官方行銷文宣把 Karakeep 描繪成無所不能的「收藏一切（Bookmark Everything）」工具，但拆開來看，每個功能都有各自的天花板。以下用懷疑論者的視角，把官方說法跟社群真實回報一次攤開來對照 📊
| 功能模組 | 官方宣傳描述 | 實際運作限制 |
|---|---|---|
| ✨ AI 自動標籤與摘要 | 丟入網址，AI 自動生成標籤並總結內容，支援 OpenAI 或本地 Ollama | 高度依賴模型智商。網頁內容過長會導致標籤品質大幅下降；遇到付費牆或 Cloudflare 盾牌，AI 只能對著錯誤頁面瞎總結 |
| 🗄️ 防失連網頁快照歸檔 | 透過 Monolith 把網頁完整拍照並轉成 PDF，徹底防範網站倒閉導致的連結失效 | 爬蟲技術有天花板。動態載入的現代 SPA 網站或反爬蟲機制強的頁面（如 Reddit）常常抓取失敗或排版跑掉 |
| ▶️ 多媒體與影片自動下載 | 自動把網址中的影片檔案下載保存到伺服器 | 貓捉老鼠遊戲。完全仰賴 yt-dlp，YouTube 只要稍微調整 API 結構，下載功能就會瞬間停擺 |
| 🎆 圖片文字辨識（OCR） | 自動抽取圖片中的文字，供全文搜尋使用 | 近期從 Tesseract 改成 LLM 為基礎的 OCR，辨識率提升，但伺服器算力或 API 成本隨之飆高 |
| 📱 跨平台存取 | iOS／Android 原生 App，加上 Chrome／Firefox／Safari 擴充功能 | 對自架使用者而言，若沒設好反向代理讓服務暴露在外網，手機一離開家中 Wi-Fi 就完全斷線失去同步能力 |
💡 碎碎念：AI 摘要其實預設是關閉的，很多人以為存了書籤就會自動生出摘要，結果打開一看是空的，這是白白踩到 INFERENCE_ENABLE_AUTO_SUMMARIZATION 這個變數預設值 false 的坑，得手動改成 true 才會生效 📌
🖥️ 系統需求與依賴風險：不是隨便一台舊電腦就跑得動
對完全不懂程式的電腦小白或銀髮族來說，Karakeep 自架版絕對不是一鍵安裝即用的輕量玩具，而是一套由多個微服務容器組成的重型全端應用程式 🚫
Web 容器是櫃檯人員，負責接單跟前端顯示；Meilisearch 容器是超高效檢索員，讓你毫秒級找到要的貨；headless Chrome 容器則是專門負責「拍照存證」的攝影師，替每個網頁拍下完整快照。三個角色缺一不可，但攝影師（Chrome）特別耗體力，這也是為什麼官方建議至少要準備 2GB 記憶體的原因 📸
| 需求維度 | 評估結果 |
|---|---|
| 基礎硬體 | 最低 1 vCPU／1GB RAM，強烈建議 2GB RAM 以上，並搭配 NVMe SSD 應付 Meilisearch 頻繁的磁碟寫入 |
| 底層依賴脆弱度 | 極高。深度依賴 Puppeteer、yt-dlp、OpenAI API，任何一個外部依賴介面異動都可能讓功能無預警停擺 |
| 資料庫架構 | 預設 SQLite（單機部署簡單），但支援無縫切換至 PostgreSQL 或 Supabase 等受管資料庫 |
| API 金鑰儲存 | 高風險。若啟用雲端 AI 標籤，OpenAI API 金鑰必須以明文形式存放在 .env 檔案中，目錄權限沒設好等於直接送給駭客 |
🚨 畫重點！千萬別踩雷：
自架安裝門檻評估只有 ⭐⭐（滿分五顆星，星數越少越難裝）。你必須自己用終端機指令生成高強度金鑰、懂 DNS 網域解析、自行設定 Nginx 反向代理與 SSL 憑證，才能讓手機 App 在外部安全連線。完全不懂程式的人幾乎不可能順利自架成功 🙅♂️
🧑🔧 DevOps 小知識：官方 Compose 檔用的無頭瀏覽器是 Zenika 的 alpine-chrome:124，不是 Karakeep 自己發布的 headless-chrome 映像檔，網路上有些舊教學會教錯映像檔名稱，記得以官方最新 docker-compose.yml 為準。另外 Meilisearch 版本請釘住 v1.41，貿然升級主版號會讓索引格式不相容，搜尋頁面直接開天窗 🪟
[29]
🎭 四種真實使用情境：你到底該不該裝？
🙋 一般輕量使用者（重度資訊囤積症患者）——適合度：高
每天在社群媒體或新聞網站上瀏覽大量資訊，透過手機 App 或瀏覽器擴充功能隨手把有趣的食譜、迷因、長篇報導一鍵存檔。AI 會在背景默默打上 #食譜、#甜點 等標籤，幾個月後只要打「鬆餅」就能精準撈出目標，徹底解決「存了等於看了、看了等於忘了」的窘境 👍 荷包濾鏡：雲端版免費方案只給 10 個書籤額度，形同展示版，真的要用大概率得升級付費 Pro 方案。
👨💻 獨立開發者與自架玩家——適合度：中
在 GitHub 或 StackOverflow 上查到的解法，或地下論壇看到的資安分析，隨時可能被原作者刪除或平台審查下架。透過單頁歸檔功能，可以把這些網頁完整打包成 PDF 存放在自己伺服器裡，打造出免疫於連結失效的個人知識庫 ✨ 但務必在伺服器資源監控上多花心思，特別是記憶體使用率，並強烈建議部署在 Tailscale 這類內網環境，若一定要對外開放，務必做好反向代理與身分驗證機制。
🏢 企業商業用途——適合度：低（需嚴格條件）
行銷或研發團隊可以利用「共享清單」功能共同建立產業新聞或競品分析資料庫，搭配 RSS 訂閱讓系統自動抓取新聞來源並初步摘要，省下大量人工整理時間 💡 但這裡有一個致命地雷，直接看下方案例。
🚨 高風險誤用場景：機密外洩的隱形漏斗
假設某企業 IT 部門在內網自架了 Karakeep 供研發團隊當知識庫，並在後端綁定了公司的 OpenAI API Key 啟用「自動摘要」。某天一位工程師為了方便稍後閱讀，把包含未公開商業機密、系統架構圖的內部 Jira 票證與尚未發布的 Confluence 專案網頁，透過瀏覽器擴充功能一鍵存入。慘劇瞬間發生：Karakeep 的爬蟲會立刻抓取這些內部機密網頁的完整純文字內容，並毫無警覺地把這些機密文字打包發送到外部的 OpenAI 伺服器，請求 AI 進行標籤推論。這個看似方便的自動化流程，直接打穿了企業的防火牆邊界，違反資料落地與隱私合規政策，釀成難以挽回的機密外洩事件 🆘
🚨 企業若真的要導入，必須強制切換為本地部署的 Ollama 模型進行 AI 推論，並嚴格阻斷容器向外網發送不明請求的能力，絕不可讓公司機密文字直接飛去第三方 LLM 伺服器 🚫
🔐 隱私與資料安全：兩起曾經爆發的高風險 CVE
作為一個處理使用者高度個人化知識庫與瀏覽紀錄的核心軟體，Karakeep 的資安防護水準是它能不能當主力生產力工具的絕對關鍵。從資安研究員視角來看，本專案在邊界防禦與輸入驗證上，仍存在令人擔憂的疏漏 ⚠️
只要啟用預設的雲端 AI 自動標籤功能，你儲存的所有網址與網頁內文，都會作為提示詞傳輸給第三方 LLM 供應商（如 OpenAI）。這代表你的閱讀偏好、關注議題甚至私人備忘錄，都不再僅限於本地伺服器。若對隱私有極高要求，必須具備足夠技術能力，手動把後端 AI 引擎改成本地部署的 Ollama 服務 🔴
| CVE 編號 | 威脅等級 | 漏洞機制 |
|---|---|---|
| CVE-2026-45082 | 🔴 高風險（CVSS 7.6） 影響版本 < 0.32.0 |
SSRF 伺服器端請求偽造。Karakeep 雖然實作了防止伺服器向內部網路發起請求的保護機制，但處理「HTTP 重新導向」時邏輯出錯——惡意攻擊者提交一個看似正常的外部網址，該網址隨後重新導向至內部 IP，爬蟲元件未再次驗證重新導向目標的安全性，導致攻擊者能誘使伺服器探測 Docker 內部網路中不應對外開放的微服務（如 meilisearch:7700、chrome:9222） |
| CVE-2026-27627 | 🔴 高風險（CVSS 8.2） 影響版本 0.30.0 |
儲存型 XSS 跨站腳本攻擊。當系統使用針對 Reddit 的爬蟲插件抓取內容時，直接接收 readableContentHtml 變數的值，卻完全跳過核心的 DOMPurify 消毒程序。攻擊者只要在 Reddit 發一段含惡意 JavaScript 的貼文，誘使使用者收藏，惡意腳本就會在打開書籤時無聲無息執行，導致使用者憑證遭竊 |
🚨 結論與建議：基於上述嚴重的 SSRF 與 XSS 歷史漏洞，企業極度不適合在未配置嚴格 WAF、未切斷容器內部不必要網路互通、以及未停用外部 AI API 的情況下，用此工具處理任何敏感或機密資料 🙅♂️
[30]
📜 授權條款：AGPL 是把雙面刃
Karakeep 核心儲存庫採用 GNU Affero General Public License v3.0（AGPL-3.0），這是自由軟體領域中「傳染性」最強、專門針對現代雲端服務設計的授權合約。企業法務團隊必須抱持最高度警戒 ⚠️
| 應用場景 | 合規性評估 |
|---|---|
| 個人或企業內部自架使用 | ✅ 無風險。只供內部員工或個人私下使用，未對外提供商業服務或散佈，完全合法免費，不須公開任何內部架構 |
| 整合進企業閉源產品 | ❌ 絕對禁止且具毀滅性風險。若把 Karakeep 程式碼或 SDK 靜態或動態連結至自家閉源商業產品，AGPL 傳染條款會被觸發，企業將被迫公開整個商業產品的原始碼 |
| 修改後作為商業 SaaS 對外提供 | ⚠️ 嚴格開源義務。若修改了原始碼並作為 SaaS 對外開放，即使沒有直接分發執行檔，仍必須向所有透過網路存取該服務的使用者提供修改後的完整原始碼 |
除了授權條款，還有兩個容易被忽略的法律灰色地帶：無差別爬蟲抓取具版權的新聞文章或付費牆內容，嚴格從法理上已侵犯內容創作者的重製權，雖然個人離線閱讀多半被認定為合理使用，但若透過「共享清單」對外公開分享，就會面臨侵權訴訟風險 🧑⚖️
💡 碎碎念：真實上演的商標權爭議。專案原名 Hoarder，2024 年底捲入嚴重商標糾紛，面對曠日廢時的訴訟威脅，開發者 Mohamed Bassem 被迫支付高達 £8,000 英鎊（約合新台幣 33 萬元）的律師費，最終妥協將專案全面更名為 Karakeep 並重新註冊新商標，這起事件深刻凸顯了獨立開源專案面對商業法律威脅時的脆弱性 ⚖️
💰 商業模式與成本風險：免費版根本是展示版
Karakeep 母公司 Localhost Labs Ltd 推出全代管的「Karakeep Cloud」雲端服務，試圖用商業模式支撐專案長遠發展 💡
- ⭐ Free 免費版：僅允許存放 10 個書籤與 20MB 儲存空間，對主打「收藏一切」的工具來說，這個限制實際上只是個試用展示版
- ⭐ Pro 專業版：解鎖至 50,000 個書籤與 50GB 儲存空間，含核心 AI 標籤與全文搜尋功能
- ⭐ Corporate 企業版：在 Pro 基礎上，提供自訂部署、網域綁定、SSO 及優先客服支援
- ⭐ 所有付費方案皆提供 7 天退款保證
🩵 荷包試算：自架版免除每月訂閱費，也不受書籤數量限制，但不代表它「免費」。使用者必須自行租用 VPS，為滿足 2GB RAM 最低需求，每月約需支出 $6 至 $12 美金不等。更危險的是API 超量計費陷阱——如果你在 .env 檔案裡綁定了自己信用卡扣款的 OpenAI API Key，決定把過去累積的 20,000 個書籤一次性批次匯入，背景工作節點會毫不猶豫地瘋狂呼叫 OpenAI API，試圖分析這兩萬篇文章的完整內文生成標籤，這個看似美好的自動化過程，極有可能一個晚上就燒掉數十甚至上百美金的 API 額度，讓荷包嚴重失血 😱
Vendor Lock-in（供應商鎖定）風險偏低：無論自架版還是雲端版，都提供一鍵匯出為 HTML、CSV 或 JSON 的功能，雲端版取消訂閱後仍保留 30 天資料匯出寬限期 👍
[31]
🏗️ 自架 vs 雲端服務，該怎麼選？
| 比較維度 | 🏠 自架版 | ☁️ Karakeep Cloud |
|---|---|---|
| 安裝與維護複雜度 | 極高，需熟悉 Linux、Docker、Nginx 反向代理與 SSL 憑證更新 | 極低，註冊帳號即可用 |
| 儲存空間與數量 | 無限制，取決於 VPS 硬碟大小 | 受限於訂閱方案，免費版僅 10 個書籤 |
| 資料主權與隱私 | 極高，可將 AI 後端指向本機 Ollama，資料 100% 不出網 | 中等，內容會傳送至第三方 AI 供應商處理 |
| 長期使用成本 | 變動成本：VPS 租金 + 浮動的 OpenAI API 費用 | 固定成本：訂閱月費／年費 |
| 功能完整性 | 100% 開源釋出 | 完全一致，省去配置 OAuth 與金鑰的麻煩 |
😤 真實使用者痛點：GitHub Issues 挖出來的四個地雷
透過深挖 GitHub Issues 與 Reddit、Unraid 討論區，我們剝開官方光鮮亮麗的文宣，找到幾個長期困擾真實使用者的技術摩擦 🔎
- ㊀ 記憶體洩漏與效能崩潰：0.30 版本發布後，大量自架使用者回報嚴重的記憶體洩漏，Node.js 核心行程與 Next.js 伺服器記憶體佔用隨運行時間不斷暴漲，最終觸發系統級 OOM 崩潰。許多用 ARM64 架構（如樹莓派 5）的玩家深受其害，官方修復前只能寫 Cronjob 腳本強制每天定期重啟容器續命 ⚠️
- ㊁ Meilisearch 搜尋引擎脆弱性：部分使用者回報搜尋引擎會無預警停止建立索引，明明剛存入的書籤卻搜不到，甚至跳出 500 錯誤。遇到資料夾權限問題或非預期關機，索引資料可能損毀，得手動刪除索引檔案並重新掃描全部書籤 🚫
- ㊂ 現代反爬蟲技術的無情阻擊：社群已確認 Reddit 啟動強烈反爬蟲機制，導致 Karakeep 無法正常抓取 Reddit 貼文內容。SingleFile 核心在特定版本也會解析網頁失敗，大量網址只能抓回一張「Access Denied」的圖片或完全空白的 HTML 檔案 🙅♂️
- ㊃ NFS 網路硬碟的檔案鎖定 Bug：把資料庫與媒體檔案掛載於網路檔案系統時，刪除帶有大型影片資產的書籤，系統會因檔案鎖定機制衝突拋出 ENOTEMPTY 錯誤導致刪除失敗，對習慣用 NAS 當底層儲存的 Homelab 玩家是個不小的痛點 ⚠️
[32]
💥 負面事件：一場意外化解為轉機的商標危機
本專案歷史上最具爭議性的事件，莫過於前文提及的「Hoarder 商標更名風波」。這起事件原本可能演變成一場災難性的公關危機，甚至讓維護者心灰意冷棄坑。開發者 Mohamed Bassem 花費數個月時間與高達 £8,000 英鎊律師費，最終妥協將專案從引以為傲的 Hoarder 改名為 Karakeep，他原本非常擔憂這次更名會扼殺專案剛在 Hacker News 上建立的熱度 😥
然而社群的真實反應出乎意料地正面。在 Reddit r/selfhosted 版塊中，大量使用者非但沒有因更名流失，反而給予了壓倒性的情感與實質支持，普遍認為開發者願意自掏腰包捍衛開源專案，展現了極度罕見的責任感。使用者紛紛留言表示「我們用的是軟體本身，玫瑰換了名字依然芬芳」「新名字在 Google 上反而更好搜尋」。這場危機最終化解為轉機，成功清除未來法律隱患，反而大幅凝聚了社群向心力 👍
🔄 替代方案冷酷比較
| 工具 | 開源與自架 | 核心優勢 | 最大缺點 |
|---|---|---|---|
| Linkwarden | 是（AGPL），支援自架 | 完美保存網頁快照與 PDF，防止連結失效能力一流，專為團隊協作設計 | 缺乏 AI 自動標籤功能，也沒有強大的自動化規則引擎 |
| Raindrop.io | 否（僅客戶端開源），不支援自架 | UI/UX 業界天花板，支援所有作業系統與瀏覽器，穩定性極高 | 完全無法自架，知識庫被綁在雲端，免費版功能受限 |
| Memos | 是（MIT），支援自架 | 系統需求極低，介面宛如 Twitter 般直覺，適合記錄靈感或輕量書籤 | 不具備完整的網頁快照與離線影片歸檔功能，僅能存純文字與短網址 |
🌳 選擇建議決策樹
- ✨ 追求極致隱私、硬體有 2GB RAM 以上、喜歡 AI 自動分類 → 選 Karakeep，它是自架生態系中 AI 整合度最高的書籤管理器
- ✨ 技術小白、只想要漂亮介面與多平台完美同步 → 選 Raindrop.io，花點小錢訂閱省去維護伺服器的無盡煩惱
- ✨ 企業級防失連、團隊協作蒐集網頁證據 → 選 Linkwarden，PDF 與快照歸檔機制更純粹穩定
- ✨ 只想回歸最純粹的卡片盒筆記，拋棄過度複雜的整理焦慮 → 選 Memos
[33]
📊 綜合風險評級：不同族群該注意什麼
| 使用族群 | 風險等級 | 建議行動 |
|---|---|---|
| 一般終端用戶（雲端版） | 🟢 低風險 | 安全修補由官方負責，唯一要留意免費版 10 個書籤限制形同虛設，需有升級付費心理準備 |
| 獨立開發者／Homelab 玩家（自架版） | 🟡 中低風險 | 密切監控伺服器資源，強烈建議部署在 Tailscale 內網環境，對外開放務必搭配反向代理與 SSO 保護 |
| 企業商業用途 | 🟠 中風險 | AGPL 傳染風險絕對不可打包進閉源產品；內部機密務必強制切換 Ollama 本地推論，阻斷容器對外發送不明請求 |
🏆 總結評分（10 分制）
| 評分維度 | 分數 | 一句話評語 |
|---|---|---|
| 功能完整性 | 9 | 完美揉合網頁快照、影片下載、OCR、AI 標籤與全文搜尋，同類軟體中的集大成者 |
| 資料安全性 | 6 | 曾爆發嚴重 SSRF 與 XSS 儲存型漏洞，API 呼叫預設路徑存在隱私外洩疑慮 |
| 法律合規性 | 7 | AGPL 限制了商業二次開發空間，爬蟲與影片下載功能永遠處於版權灰色地帶 |
| 安裝易用性 | 5 | 自架版需處理多容器編排、外部 API 金鑰綁定與反向代理，對非技術人員門檻偏高 |
| 文件完整性 | 8 | 官方提供相當完整的 Docker 部署、變數說明與跨伺服器移轉手冊 |
| 維護活躍度 | 9 | 經歷商標風波與高額律師費打擊後，依然保持極高頻率更新修補，社群向心力極強 |
| 🏆 加權總分 | 7.3 | 最終建議：【謹慎使用，強烈推薦給 Homelab 進階玩家與資訊囤積狂】 |
🔥 Karakeep 是一個野心勃勃且功能極度強大的「個人數位大腦」，用 AI 巧妙解決了傳統書籤管理中最核心的「分類疲勞」問題。但它是一頭需要精細照料的猛獸——不僅吞噬伺服器硬體資源，廣泛的網路請求與爬蟲機制也曾帶來嚴重資安漏洞，更經歷了浴火重生般的商標法律戰。只要你不把企業機密輕易丟進去，並具備基礎 Docker 運維能力，這套系統會是你對抗「網路資訊消逝」與「書籤破產」最強大的武器 💪
💪 附錄：Docker Compose 安裝教學
以下整理自官方文件與多份社群實測教學，適合有基礎 Docker 概念的自架玩家跟著操作 📌
㊀ 建立資料夾並下載官方 Compose 檔
mkdir karakeep-app && cd karakeep-app wget https://raw.githubusercontent.com/karakeep-app/karakeep/main/docker/docker-compose.yml
㊁ 建立 .env 環境變數檔
在同目錄下建立 .env 檔，至少要包含以下最小設定：
KARAKEEP_VERSION=release NEXTAUTH_SECRET=super_random_string MEILI_MASTER_KEY=another_random_string NEXTAUTH_URL=http://localhost:3000
🚨 NEXTAUTH_SECRET 與 MEILI_MASTER_KEY 這兩組亂數字串務必自己生成，不要沿用範例值，否則等於把大門鑰匙插在門上，可用 openssl rand -base64 36 指令生成強度足夠的隨機字串 🔑
㊂ 啟動服務
docker compose up -d
接著造訪 http://localhost:3000，第一個註冊的帳號會自動成為管理員，建立好帳號後立刻把 DISABLE_SIGNUPS=true 加進 .env 並重新 docker compose up -d，關閉公開註冊入口 ⭐
㊃ 設定 AI 自動標籤（選用）
使用 OpenAI 的話，最簡設定只要一行：
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
若想完全不出網、使用本地 Ollama 模型，則改用官方目前建議的 OpenAI 相容端點寫法：
OPENAI_API_KEY=ollama OPENAI_BASE_URL=http://ollama.mylab.com:11434/v1 INFERENCE_TEXT_MODEL=gemma3 INFERENCE_IMAGE_MODEL=llava
🫂 新手求助：如果 AI 標籤完全沒反應，通常是三個原因之一——OPENAI_API_KEY 打錯字、改完 .env 忘記重跑 docker compose up、或是 OpenAI 帳戶沒有餘額。容器日誌（docker compose logs karakeep）通常會直接告訴你是哪一種狀況。官方完整環境變數文件在 docs.karakeep.app，GitHub Issues 區的社群回覆速度也相當快 🆘
㊄ 反向代理與 HTTPS（正式上線必做）
不建議直接把 3000 埠裸露在公網，建議搭配 Caddy 這類自動申請憑證的反向代理伺服器，設定一個對應的 Caddyfile 指向內部服務即可自動取得 Let’s Encrypt 憑證 ✅
㊅ 備份
Karakeep 的完整狀態存在兩個目錄：資料庫、上傳資產與截圖所在的資料目錄，以及可重建但速度較慢的 Meilisearch 索引目錄。最簡單可靠的做法是排程一支每日打包這兩個目錄的備份腳本，並考慮異地備份到 S3 相容儲存空間 ⭐
🧑🔧 DevOps 小知識：更新策略取決於 KARAKEEP_VERSION 怎麼設。若用 release 頻道，單純跑 docker compose up -d 不會真的抓新版本，必須加上 –pull always 參數強制拉取最新映像檔；若是釘死特定版號，則要先在 .env 手動更新版號字串再重跑指令 ⚙️
[34]
📚 參考資料與延伸資源
- 📌 Karakeep 官方 GitHub 專案 [1]
- 📌 Karakeep 官方文件 [35]
- 📌 Karakeep 官方 Docker 安裝文件 [36]
- 📌 Karakeep 環境變數說明文件 [37]
- 📌 CVE-2026-45082 官方紀錄（NVD） [38]
- 📌 SSRF Protection Bypass 安全公告（GitHub Advisories） [39]
- 📌 CVE-2026-27627 官方紀錄（NVD） [40]
- 📌 Karakeep Cloud 定價頁面 [41]
- 📌 Karakeep 授權條款（AGPL-3.0） [42]
- 📌 Hoarder 更名 Karakeep 社群討論（Reddit r/selfhosted） [43]
- 📌 Karakeep on Railway 部署範本 [44]
- 📌 Self-Host Karakeep on a VPS with Docker and Caddy（RDP.sh） [45]