Vaultwarden 是一套以 Rust 撰寫的 Bitwarden 相容伺服器，在 GitHub 累積 68,745 顆星標與 3,293 次複製，由社群獨立維護，採用 AGPL-3.0 授權。專案原名 bitwarden_rs，2018 年 2 月建立，目標是讓使用者以極低的硬體資源自行架設密碼管理服務，同時保持與官方 Bitwarden 應用程式的相容性。2026 年 10 月 5 日，專案發布 1.37.4 版，修補兩個安全問題。
Vaultwarden 是什麼？
它是一套以 Rust 重寫的 Bitwarden 用戶端 API 伺服器，可搭配官方 Bitwarden 應用程式使用，專為資源有限的自行架設環境設計。
Vaultwarden 的定位並非另創一套密碼管理標準，而是以較輕量的方式重現 Bitwarden 用戶端所需的伺服器端介面。使用者仍舊從官方 Bitwarden 的瀏覽器擴充套件、桌面程式與行動應用登入，但資料儲存在自己掌控的伺服器上。這種做法讓既有的用戶端生態得以直接沿用，也讓伺服器端的資源需求大幅下降。
專案的起源與命名反映其社群性格。它最初以 bitwarden_rs 之名流通，為了避免與官方產品混淆以及商標爭議，於 1.21.0 版更名為 Vaultwarden。文件明確聲明專案與 Bitwarden 公司無關，但也說明其中一位主要維護者受僱於 Bitwarden，並以個人時間參與開發，相關貢獻獨立於公司之外並經其他維護者審查。
從維護規模觀察，專案已有超過兩百位貢獻者參與，目前累積三十個正式版本。程式碼以 Rust 撰寫，主要語言佔比集中，並採用 Rocket 網頁框架。這種技術選擇同時回應了兩個需求：密碼管理服務對記憶體安全的要求，以及社群對低資源佔用的期待。
Vaultwarden 與官方 Bitwarden 伺服器有何不同？
兩者提供相容的用戶端 API，差別在資源需求與維護模式：Vaultwarden 以輕量、低記憶體佔用為優先，由社群維護，官方伺服器則由 Bitwarden 公司支援。
最直接的差異是硬體門檻。官方 Bitwarden 伺服器需要較完整的服務堆疊與資料庫環境，Vaultwarden 則以單一容器配合 SQLite 為預設路徑，對小型團隊、家庭使用者與單板電腦而言更為可行。README 亦指出，專案適合在官方服務過於吃重的情況下自架部署。
第二項差異是相容範圍的取捨。Vaultwarden 實作「幾乎完整」的 Bitwarden 用戶端 API，涵蓋個人保險庫、Send、附件、網站圖示、個人 API 金鑰、組織與集合、成員角色、群組、事件記錄、管理員密碼重設、目錄連接器與政策，亦支援多因素驗證、緊急存取與修改版網頁保險庫。部分企業級功能則不在實作範圍內。
第三項差異在支援管道。專案明確要求使用者將錯誤與建議回報至自身的討論區與議題追蹤器，不得使用官方 Bitwarden 的支援管道。這種分工一方面避免社群問題湧入官方客服，另一方面也提醒使用者：相容並不等同於官方支援，關鍵服務的維運責任仍在自己身上。
Vaultwarden 具備哪些核心功能？
它涵蓋個人保險庫、附件、Send、組織與集合共享、事件記錄與緊急存取，並支援 TOTP、電子郵件、FIDO2 WebAuthn、YubiKey 與 Duo 驗證。
核心功能圍繞個人與組織兩個層次展開。個人層面提供保險庫管理、附件上傳、文字與檔案形式的 Send 分享、網站圖示抓取，以及供自動化工具使用的個人 API 金鑰。這些項目與官方用戶端的操作經驗一致，使用者不需要重新學習流程。
組織層面的實作則對應團隊協作需求。集合與密碼分享、成員角色與群組權限、事件記錄、管理員密碼重設、目錄連接器與組織政策均在其中，並包含組織成員的加入、停權與撤銷流程。對於需要集中管理帳號存取的中小團隊，這一組功能決定了它能否取代官方伺服器。
驗證機制同樣完整。除常見的驗證器應用與電子郵件驗證碼之外，專案支援 FIDO2 WebAuthn 安全金鑰、YubiKey 與 Duo，並提供緊急存取功能，讓指定對象在帳號持有人無法回應時取得存取權。這些機制對於避免單點失效具有實際意義。
Vaultwarden 的技術架構有何特點？
它以 Rust 撰寫並採用 Rocket 網頁框架，預設以容器搭配 SQLite 部署，官方建議在前方加上反向代理並啟用 HTTPS，以符合網頁保險庫的安全需求。
架構的第一個選擇是語言。Rust 的記憶體安全特性，對於必須長期存放密碼與憑證的服務具有直接價值，也讓專案在資源佔用上維持在較低水準。第二個選擇是網頁框架，專案以 Rocket 為基礎，該框架本身具備 TLS 支援，但官方仍建議由反向代理處理對外連線。
部署形態以容器為主。專案將映像檔發布至 ghcr.io、docker.io 與 quay.io 三個登錄處，README 同時示範以 Docker 或 Podman 直接啟動，以及以 Docker Compose 管理設定，並將資料目錄掛載至主機以保留持久資料。對熟悉容器工作流程的使用者而言，導入成本相當低。
安全前提在文件中被反覆強調。網頁保險庫依賴 Web Crypto API，因此必須在 HTTPS 與安全脈絡下才能運作，專案在說明中直接標示此限制，並指向自身的 HTTPS 設定與反向代理範例頁面。此外，專案也提供可選的管理後台，供使用者檢視與調整伺服器層級設定。
如何自架 Vaultwarden？
最簡路徑是拉取官方容器映像，設定網域環境變數並掛載資料目錄後啟動，再依需求設定 HTTPS 與反向代理，即可用官方 Bitwarden 應用程式連線。
入門方式相當直接。使用者可從 ghcr.io 或 Docker Hub 取得映像檔，以單一指令啟動容器，並透過環境變數指定對外網域，同時將主機目錄掛載至容器內的資料路徑，確保資料在容器重建後仍能保留。若偏好宣告式設定，專案亦提供 Compose 檔案範例。
完成啟動之後，還需要處理對外存取的安全設定。由於網頁保險庫必須在 HTTPS 環境下運作，使用者通常會在容器前方加上反向代理，由代理負責憑證與加密連線，再將請求轉送至本機連接埠。專案文件中列出多種代理設定範例，並說明如何啟用 HTTPS。
對於不想自行維護的環境，社群亦提供第三方套件，但專案提醒這些套件可能落後於最新版本，或採用不同的設定方式，使用前應先查閱說明文件。這種風險提示反映自架服務的共通原則：便利性與版本落後之間需要自行權衡。
Vaultwarden 1.37.4 修補了哪些問題？
1.37.4 於 2026 年 10 月 5 日發布，修補組織成員撤銷與兩步驟驗證兩個安全問題，其中前者嚴重度評分為 8.1，官方建議儘快更新。
本次更新被歸類為安全修補。專案在發布說明中列出兩個安全公告，第一項涉及組織成員的撤銷流程，嚴重度評分為 8.1，屬於高等級問題；第二項與兩步驟驗證相關。專案在說明開頭即以明確語氣建議使用者儘快更新，而非等待下一次功能版本。
這次更新延續的是小型版本快速修補的模式。前一個版本 1.37.3 以錯誤修正為主，包含修正較新網頁保險庫的密碼變更流程、忽略郵件功能停用時的重設密碼自動註冊，以及若干設定遷移問題；更早的 1.37.2 則要求用戶端升級至 2026.8.0 以上，以維持相容性。
維護節奏值得留意。專案以容器映像檔的形式發布，使用者更新時只需要更換映像標籤並重建容器，資料目錄不受影響；但正因為部署容易，使用者也可能長期停留在舊版本，而錯過安全修補。對自架密碼庫而言，建立定期檢查版本的習慣，比一次性完成部署更為關鍵。
Vaultwarden 的統計數據與授權條件為何？
專案累積 68,745 顆星標與 3,293 次複製，以 AGPL-3.0 授權開放，主要語言為 Rust，目前有超過兩百位貢獻者與三十個正式版本。
授權條件是這套方案的重要前提。AGPL-3.0 屬強著作權傳染型授權，允許自由使用、修改與散布，但要求衍生作品以相同條款釋出，並在使用者透過網路互動時提供原始碼。對個人自架使用者而言幾乎不構成負擔，對打算將程式碼納入閉源產品的商業團隊則需特別評估。
專案在免責聲明中亦明確劃清責任界線。文件指出，因使用本專案而導致的資料遺失，包括密碼、附件與其他由應用程式處理的資訊，維護者不承擔責任，並強烈建議使用者定期備份檔案與資料庫。這項提醒在自架情境下格外實際，因為資料的唯一副本掌握在使用者自己手中。
出處連結有哪些？
本文資訊整理自 dani-garcia/vaultwarden 的 GitHub 儲存庫與發布說明，涵蓋功能範圍、技術架構、部署方式、安全修補與授權條件。
- GitHub 儲存庫：https://github.com/dani-garcia/vaultwarden
- 官方 Wiki：https://github.com/dani-garcia/vaultwarden/wiki
- 1.37.4 發布說明：https://github.com/dani-garcia/vaultwarden/releases/tag/1.37.4
- 專案討論區：https://github.com/dani-garcia/vaultwarden/discussions
- AGPL-3.0 授權條款：https://github.com/dani-garcia/vaultwarden/blob/main/LICENSE.txt
總結：Vaultwarden 適合什麼團隊？
它適合重視資料自主、具備基礎容器維運能力的個人與中小團隊；若需要官方企業級支援或完整的企業功能，仍應選擇官方伺服器方案。
Vaultwarden 的價值在於把密碼庫的掌控權交回使用者手中，同時不犧牲既有的用戶端體驗。它以 Rust 換取較低的資源需求，以容器換取簡單的部署流程，以相容的 API 換取沿用官方應用程式的便利，並以 AGPL-3.0 確保程式碼持續開放。對於資源有限卻希望自行保管憑證的個人、家庭與小型團隊，它的門檻確實不高。
但自架並非零成本。使用者需要自行處理 HTTPS 與反向代理設定、定期備份資料庫、追蹤安全版本，並承擔服務中斷與資料遺失的風險。若團隊缺乏基本的容器與網路維運能力，或業務上需要供應商承諾的支援與企業級功能，那麼維護一套自架服務所投入的時間，未必低於採用官方方案的費用。選擇的關鍵仍在於：團隊要的是控制權，還是省下維運的人力。