HashiCorp 在 2023 年 8 月把整套產品線從 MPL 2.0 改成 BUSL 1.1，Vault 1.14 是最後一個開源版本。當時社群第一時間的反應是不安，但能拿來填補位置的開源 fork 並沒有立刻成形——Terraform 那一側有 OpenTofu 火速接管，Vault 這邊則拖了將近一年才有正式可用的東西。OpenBao 在 2026 年 2 月 4 日推出 2.5.0，這是它從一個「IBM 工程師私下維護的 fork」走到「Linux Foundation 旗下、PostgreSQL 後端可用、橫向讀取可擴展」的轉捩點。對於還在用 Vault 1.14 LTS 拖時間、或者根本沒導入 secrets management 的團隊，這個版本是重新評估的時機。
BUSL 對自架使用者真正麻煩的地方
Business Source License 表面上看起來跟 MPL 沒差太多——可以讀原始碼、可以改、可以自架——但條款裡塞了一句「不得用於與授權方競爭的產品或服務」。問題在於「競爭」這兩個字的解釋權在 HashiCorp 手上。一家臺灣的雲端服務商如果想把 Vault 包進自家的代管產品提供給客戶，理論上就踩到了紅線；即使是內部使用，只要公司有任何對外的 SaaS 服務，法務檢查時都會把這條標出來。
第二個現實問題是版本支援。HashiCorp 把 1.14 之後的 patch 全部關進 BUSL，安全修補只回流到企業版客戶。社群版繼續用 1.14 等於是公開地停在一個越來越多 CVE 的版本上，每一次 audit 都會被指出來。
對於業務上不需要 Vault 企業版功能（HSM、performance replication、Sentinel policy）的中小團隊，這兩個問題加起來等於一個明確訊號：要嘛升級成付費客戶，要嘛找替代品。前者通常超出預算，後者過去一年半都沒有夠成熟的選項。OpenBao 把這個缺口補上。
從 Vault 1.14 fork 出來的兩年半
OpenBao 不是新寫的專案，它的程式碼基底就是 Vault 1.14.0。IBM 的工程師 Nathan Phelps 跟 Joe Pearson 在 2023 年底發起，2024 年 4 月進入 LF Edge 旗下成為正式專案，binary 名稱從 vault 改成 bao。值得一提的是，雖然 IBM 後來在 2025 年初完成併購 HashiCorp，OpenBao 在治理上維持獨立——專案路線由 TSC 決定，不受 IBM 的產品策略左右。
API、CLI 指令、secret engine、auth method、storage backend、policy 語法全部跟 Vault 相容。已經寫好的 Terraform provider、Ansible playbook、應用程式裡的 Vault SDK 客戶端，幾乎都能不改一行直接指向 OpenBao。這是 fork 策略選對方向的結果：先保證遷移成本接近零，再慢慢累積差異化功能。
兩年半下來，OpenBao 走了三個重要里程碑。2.1 加入 PostgreSQL storage backend，這對只想用一台 VPS 跑 secrets management 的團隊意義重大——過去 Vault 在 HA 模式下強制要 Consul 或 Integrated Storage（Raft），前者要額外維護整套 Consul 叢集，後者在 Vault 階段就已經穩定，但 OpenBao 把 PostgreSQL 也納進候選名單，等於讓既有的 Postgres 實例多承擔一個角色，少開一台機器。2.3 補上 transactional storage 與更乾淨的 plugin SDK。2.5 則是把 horizontal read scalability 跟 OCI plugin 分發兩個比較困難的功能做完。
2.5 真正改變使用情境的兩件事
2 月 4 日的 release notes 列了一長串改動，多數是 patch 與 enhancement，但有兩項對日常使用影響特別大。
Standby 節點可以直接服務讀取請求。 在 Vault 跟先前版本的 OpenBao 中，HA 架構裡的 standby 節點純粹是備援，所有讀寫都要轉發給 active leader。應用程式拿 secret 是壓倒性的讀取操作——CI/CD 啟動時拉資料庫密碼、應用程式啟動時拉 API key、cert-manager 簽憑證——尖峰時這些請求全擠到 leader 一台機器上。2.5 開始 standby 節點可以本地處理唯讀請求，寫入仍轉發給 leader 維持強一致性。對於同一個 OpenBao 叢集要服務上百個 microservice 的場景，這項變動可以把讀取吞吐量直接翻三到五倍，而且不用改客戶端設定，現有 sidecar 跟 SDK 自動受惠。
Plugin 可以宣告式地從 OCI registry 拉下來。 過去要在 Vault 上裝第三方 plugin 是一段繁瑣流程：把 binary 上傳到 server、註冊 SHA256、啟用 plugin、設定 mount。2.5 引入 declarative plugin distribution，可以在 server 設定檔裡直接寫 image = "ghcr.io/example/bao-plugin-foo:v1.2.0"，OpenBao 啟動時自動拉、驗證簽章、註冊。把 plugin 管理納入 IaC 流程之後，重建叢集不再需要手動補 plugin 這個步驟。對於需要客製化 secret engine 或 audit device 的團隊特別有用。
附帶的還有 OIDC Provider 補上 Client Credentials flow（讓 OpenBao 直接當 machine-to-machine OIDC IdP）、audit 多了 HTTP webhook device（低流量場景可以直接推到 Slack 或 Discord）、stricter path validation 把幾個歷史遺留的權限繞過漏洞收掉。
從 Vault 搬過來會在哪些地方卡住
完全相容是 OpenBao 的設計目標，但實務上有幾個邊角要先確認。
企業版功能是第一個。如果環境有用到 HSM 整合（Vault Enterprise 的 Auto-unseal HSM）、performance replication、Sentinel policy、DR replication、MFA via Duo/PingID 這些只在企業版的東西，OpenBao 沒有對等實作。Auto-unseal 用 cloud KMS 那一支倒是社群版就有，沒受影響。
第二個是 plugin 生態。Vault 的官方 plugin 走 HashiCorp 的 registry，部分 plugin 在 BUSL 之後也跟著鎖授權。OpenBao 自己維護的 plugin registry 還在補齊，常見的 database plugin、SSH plugin、AWS plugin 都已經 fork 過來且持續更新，但比較冷門的第三方 plugin（某些雲廠商的 dynamic credentials）可能要自己編。
第三個是 Terraform provider。HashiCorp 的 hashicorp/vault provider 仍可使用，因為它走的是 HTTP API；社群另外維護了 openbao/openbao provider 提供原生介面，差異主要在於後者跟著 OpenBao 的新功能更新更快。兩個都能用，但建議新專案直接走 openbao/openbao 避免將來踩到 HashiCorp 的授權邊界。
實際搬遷流程是這樣：先用 vault operator raft snapshot save 匯出現有資料；架一個 OpenBao 叢集，初始化但不 unseal；把 snapshot 用 bao operator raft snapshot restore 灌進去；驗證 secret engine、policy、token 都能讀；切換客戶端的 endpoint。整個過程通常一個下午可以做完，前提是事先把 Vault 跟 OpenBao 版本對齊（OpenBao 2.5 對應 Vault 1.14 為基底，但已經往前疊了兩年的修補）。
在臺灣的 VPS 上跑 OpenBao 的最小可用設定
KVM-based VPS 都能跑，記憶體 1 GB 起跳；2 GB 比較舒服，留空間給 PostgreSQL。儲存後端有三個合理選擇：
- 單機測試用 file backend 就夠，設定一行
storage "file" { path = "/opt/bao/data" }。 - 正式環境的單機部署建議 PostgreSQL backend，跟既有的 Postgres 共用，省一台 VM。
- 真的需要 HA 才上 Integrated Storage（Raft），三節點起跳，每節點獨立的 disk。
TLS 千萬不要省。內部 service mesh 已經 mTLS 的情境可以用 PROXY protocol 把 TLS 終止在前面的 reverse proxy，否則直接讓 OpenBao 自己拿 Let’s Encrypt 憑證，或者用 Caddy 做 reverse proxy 自動處理 ACME。Audit log 一定要開——OpenBao 預設不開 audit，但只要任何 request 失敗它就會自我關閉，所以這項要在初始化後馬上啟用，否則第一次 storage write 失敗整個服務就停掉。
Auto-unseal 是上正式環境的另一個關鍵。如果靠人手 unseal，每次重啟服務都得有人在線輸入 unseal key，這在自動化部署裡完全不可行。把 unseal 委派給 AWS KMS、Google Cloud KMS、Azure Key Vault 是常見做法，臺灣本地沒有對等服務，務實做法是用海外雲廠商的 KMS 加上嚴格的 IAM policy，或者用另一個 OpenBao 實例的 Transit secret engine 來達成同樣效果。
備份這件事容易被忽略但代價最高。OpenBao 的資料一旦掉了沒有救援機制——加密 key 在 master key 裡、master key 用 unseal key 解、unseal key 五份分散。建議搭配 Restic 把整個 storage backend 加密增量備份 到異地物件儲存，這比 snapshot 單檔複製安全得多。
對於還在猶豫要不要把 secrets 從 .env 檔搬出來的團隊，OpenBao 2.5 把過去 Vault 在自架場景的痛點降到最低：相容、可擴展、明確的開源授權、不用支付企業版授權費。在臺灣選擇穩定的 VPS 環境跑 OpenBao 並做好異地備份，是兼顧成本與資料主權的務實組合。NCSE Network 提供位於是方電訊機房、Intel Gold CPU 與 NVMe SSD 的 VPS 方案，適合用來承載 OpenBao 這類需要低延遲存取的核心基礎設施；如果規模擴大需要多機 HA，也可以延伸到機房代管。詳情請至 NCSE Network 了解。
