简介
Vaultwarden 是一个使用 Rust 编写的开源密码库服务端，目标是兼容官方 Bitwarden 客户端 API，让用户继续使用熟悉的浏览器扩展、桌面端、移动端和命令行客户端，同时把服务端部署在自己的服务器、NAS 或 VPS 上。它适合把数据控制权列为明确需求，并且有能力长期维护域名、HTTPS、备份和安全更新的个人、家庭与小型团队。
杂货喵小编结合 Vaultwarden GitHub 仓库、README、Wiki、Release 与 WarpNav 收录资料重新整理，以部署决策和长期维护为主线，说明它与 Bitwarden 官方服务的关系、适合哪些用户，以及上线前必须完成的安全准备。截至 2026 年 7 月核对时，项目采用 AGPL-3.0 许可证，最新正式版为 1.36.0。
本文要点
- Vaultwarden 是非官方 Bitwarden 兼容服务端，不属于 Bitwarden, Inc.
- 可配合官方 Bitwarden 浏览器、桌面、Android、iOS 与 CLI 客户端。
- 推荐使用 GHCR、Docker Hub 或 Quay.io 提供的容器镜像部署。
- Web Vault 必须运行在 HTTPS 安全上下文中，官方建议配置反向代理。
- 自托管不会自动更安全，更新、监控、备份和恢复均由部署者负责。
Vaultwarden 和 Bitwarden 是什么关系
Vaultwarden 实现的是 Bitwarden Client API 的兼容服务端，项目早期名为 Bitwarden_RS，后来为减少品牌混淆而更名。它能够连接官方客户端，但不是 Bitwarden 官方服务器的精简版本，也不由 Bitwarden, Inc. 提供支持。遇到服务端问题，应查阅 Vaultwarden 自己的 Wiki、Issue 和社区渠道。
这种兼容方式的优势是客户端学习成本较低：已有 Bitwarden 使用习惯的人，主要需要修改自托管服务器地址，而不是重新适应另一套密码管理界面。代价是兼容实现可能与官方服务存在功能或版本差异，客户端和服务端大跨度升级前应先查看当前 Release 与已知问题。
部署前先确认这些条件
| 条件 | 最低准备 | 缺失时的风险 |
|---|---|---|
| 域名与 HTTPS | 独立域名、有效证书、反向代理 | Web Vault 无法在安全上下文中正常工作 |
| 持久化数据 | 把容器 /data 映射到稳定存储 |
重建容器可能丢失数据库、附件与配置 |
| 访问控制 | 限制注册、保护管理页、使用强管理员令牌 | 扩大未授权访问和配置泄露风险 |
| 备份恢复 | 加密、异地、带版本备份并定期演练 | 只有备份文件却无法实际恢复 |
| 持续更新 | 关注 Release 与安全公告，先备份再升级 | 长期停留在含已知问题的旧镜像 |
如果这些条件只能在安装当天满足，而无法长期执行，直接使用成熟的托管密码管理服务通常更稳妥。密码库是高价值数据，自托管的重点不是“把容器跑起来”，而是持续保证服务、证书、存储、备份和升级都处于可恢复状态。
核心能力与适用边界
个人保险库与跨设备同步
Vaultwarden 提供个人保险库、Send、附件、网站图标和个人 API Key 等能力，可通过兼容客户端管理登录信息、安全笔记、身份资料等条目。服务器地址配置正确后，用户可以在不同设备间同步，但应避免把服务暴露在缺乏 TLS、弱口令或长期不更新的环境中。
组织、集合与共享
组织、集合、成员角色、群组、事件日志、管理员重置密码、目录连接器和策略等功能，可用于家庭或小团队划分共享范围。对于需要正式 SLA、厂商支持、合规证明、集中身份治理和复杂审计的企业，不能只看功能清单，还要评估支持责任、兼容性和组织风险。
多因素认证和紧急访问
项目列出验证器、电子邮件、FIDO2 WebAuthn、YubiKey、Duo 与紧急访问等能力。开启功能只是第一步，仍需正确设置域名、HTTPS、时间同步、恢复方式和管理员访问策略，避免在设备遗失或二次验证故障时把自己锁在密码库之外。
Docker 部署的基本流程
- 准备长期可维护的 Linux 主机或 NAS、独立域名和稳定存储。
- 从官方 GHCR、Docker Hub 或 Quay.io 镜像渠道选择合适标签。
- 把容器内
/data映射到持久化目录，并限制目录权限。 - 设置实例
DOMAIN，在前方配置 HTTPS 反向代理。 - 关闭不需要的公开注册，保护管理员令牌和管理入口。
- 创建首次备份并在隔离环境验证恢复，再开始正式迁移密码数据。
Docker 与 Podman 都可以作为容器运行入口，Compose 更适合保存可复核的配置。第三方 NAS 套件或社区镜像可能落后于官方版本，也可能修改默认路径和配置方式；采用前应核对来源、维护频率和数据目录，不能只看安装是否方便。
安全维护清单
- 更新：订阅 Release 和安全公告，升级前备份并准备回滚。
- 备份：覆盖数据库、附件、密钥、配置及外部数据库，采用异地加密副本。
- 恢复：定期在隔离环境演练，确认客户端可重新登录和同步。
- 暴露面：限制管理页和注册入口，检查反向代理、端口与防火墙规则。
- 监控：关注磁盘、证书到期、容器重启、登录异常和备份失败。
项目 README 明确提醒使用者可能遇到数据丢失，并建议定期备份文件和数据库。只做数据库快照但遗漏附件、配置或外部存储，也可能导致恢复后的实例不完整；备份范围要与自己的实际架构一致。
适合人群
Vaultwarden 更适合已有家庭服务器、NAS 或 VPS 的技术用户，需要与家人共享密码的家庭，以及具备 Linux、容器、反向代理和备份维护能力的小型团队。它也适合希望研究 Rust 服务端和密码管理架构的开源用户。
没有服务器经验、无法持续更新、没有异地备份，或必须依赖厂商 SLA、合规认证与正式技术支持时，不建议仅为了“自托管”而部署。托管方案把部分基础设施责任交给专业团队，可能更符合这类用户的风险承受能力。
编辑整理体验
Vaultwarden 最有吸引力的地方，是把成熟的 Bitwarden 客户端体验和自有服务端结合起来。用户不用重新学习密码管理客户端，部署者也能控制域名、数据位置、注册策略和备份介质，适合边界明确的小规模使用场景。
它也很容易被误解成“装好 Docker 就完成了”。真正的成本集中在后续：证书续期、镜像更新、数据库与附件备份、恢复演练、异常监控和安全响应。密码库长期可用的价值远高于一次安装成功，因此维护能力应成为选型第一条件。
常见问题（FAQ）
Vaultwarden 是 Bitwarden 官方项目吗？
不是。Vaultwarden 是独立社区维护的非官方 Bitwarden 兼容服务端，可以配合官方客户端使用，但项目问题应提交给 Vaultwarden 社区。
自托管一定比云端更安全吗？
不一定。数据位置更可控，但服务器配置、TLS、更新、管理员权限和备份都由自己负责。维护不足时，自托管实例的风险可能更高。
为什么必须配置 HTTPS？
Web Vault 依赖 Web Crypto API 的安全上下文，官方 README 明确要求启用 HTTPS，并建议在 Vaultwarden 前方配置反向代理。
升级前需要做什么？
先阅读 Release 说明，确认镜像标签和兼容变化；备份持久化数据并验证备份可用，再重建容器，同时保留可执行的回滚方案。
备份整个 /data 就够了吗？
默认结构下它覆盖许多关键文件，但使用外部数据库、对象存储或自定义配置时，还要把对应服务纳入备份。应以实际部署架构制定恢复清单。
部署建议
准备采用 Vaultwarden 时，先用测试域名建立临时实例，完成 HTTPS、客户端连接、注册策略、备份和恢复演练，再迁移真实密码数据。不要直接把唯一密码库导入尚未验证的容器，也不要长期使用来源不明或无人维护的第三方打包。
正式运行后，把更新检查、证书到期、备份结果和恢复演练写入固定维护计划。项目版本与兼容性会持续变化，部署和升级时应以 GitHub README、Wiki、Release 与 AGPL-3.0 许可证原文为准。
- 最新
- 最热
只看作者