Vaultwarden：用 Rust 重写 Bitwarden 服务端，自托管密码库的轻量选择
用 Rust 编写的非官方 Bitwarden 兼容服务器，以前称为 bitwarden_rs。
秒懂
- 它是什么？
- Vaultwarden 是一个兼容 Bitwarden 客户端 API 的开源服务端，用 Rust 编写，专为自托管场景设计。本文基于其 README 和仓库信息，分析其功能范围、部署方式、局限性与适用人群。
- 适合谁用？
- Vaultwarden 适合那些希望完全掌控密码库数据、且不愿为官方 Bitwarden 服务端的高资源占用买单的个人或小团队。它不适合需要官方支持渠道、或依赖 Bitwarden 企业版特有功能（如某些高级策略）的用户。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：官方服务端太重，自托管需要替代品
Bitwarden 官方提供自托管服务端，但官方实现基于 .NET 和 SQL Server，资源消耗较高，在树莓派或小型 VPS 上运行吃力。Vaultwarden 用 Rust 重写了 Bitwarden 客户端 API，目标是提供一个轻量、低资源占用的替代服务端，让个人或小团队能在普通硬件上自托管密码库。它并非从零发明新协议，而是兼容现有 Bitwarden 客户端，这意味着你仍可使用官方桌面、移动端和浏览器扩展。项目原名为 bitwarden_rs，后来更名为 Vaultwarden，以明确它并非官方项目。
API 兼容性覆盖到哪：一个近乎完整的客户端 API
README 声称提供了“近乎完整”的 Bitwarden 客户端 API 实现。具体功能包括个人密码库、Send、附件、网站图标、个人 API 密钥，以及组织相关的集合、密码共享、成员角色、组、事件日志、管理员密码重置、目录连接器和策略。多因素认证支持 Authenticator、Email、FIDO2 WebAuthn、YubiKey 和 Duo。还有紧急访问功能。此外，项目自带一个修改版 Web Vault 客户端，打包在容器镜像中。这个覆盖面足以满足大多数个人和家庭用户，但“近乎完整”意味着某些边缘功能可能缺失或行为略有不同，具体差异需要查阅 Wiki 或提交 issue 确认。
部署方式：容器镜像为主，也有社区包和源码构建
官方推荐的部署方式是通过容器镜像，镜像发布在 ghcr.io、docker.io 和 quay.io。Docker CLI 示例很直接：拉取 vaultwarden/server:latest，运行时挂载 /vw-data/ 目录作为持久化存储，并设置 DOMAIN 环境变量指向你的域名。端口映射通常建议绑定到 127.0.0.1:8000，前面再放一个反向代理处理 HTTPS。README 明确提到，Web Vault 依赖 Web Crypto API，需要 HTTPS 安全上下文，因此反向代理几乎是必需的。除了容器，还有社区维护的第三方包，但 README 提醒这些包可能滞后于最新版本，或配置方式与官方容器不同。你也可以从源码构建，但需要 Rust 工具链。
一个关键约束：HTTPS 不是可选项，而是硬性要求
README 用 IMPORTANT 标记强调，Web Vault 需要 HTTPS 和安全上下文才能使用 Web Crypto API。这意味着如果你直接通过 HTTP 访问 Vaultwarden 的 Web 界面，加密和解密操作会失败。官方建议启用 HTTPS，并提供了反向代理配置示例的 Wiki 链接。虽然 Rocket 框架本身支持 TLS，但 README 仍建议使用反向代理，这可能是为了简化证书管理和负载均衡。对于初学者，这增加了一层配置成本，但也是安全性的必要保障。如果你只想用命令行或 API 客户端，可能不需要 HTTPS，但 Web 界面和浏览器扩展会受影响。
维护与升级成本：社区驱动，发布节奏活跃
仓库最近一次推送是 2026 年 8 月 22 日，发布了 1.37.2 版本，此前 1.37.1 和 1.37.0 分别在 7 月底和 7 月中旬发布。这说明项目维护活跃，大约每月有一次小版本更新。升级成本取决于你的部署方式：容器镜像更新只需拉取新标签并重启容器，但需要注意数据卷的兼容性。社区包可能滞后，所以如果你依赖第三方包，升级前要检查版本。由于项目是 AGPL-3.0 许可，如果你修改代码并分发，必须提供源代码。这主要影响那些想二次开发并对外提供服务的人，个人使用则没有额外负担。
一个真正的限制：不是官方产品，出问题别找 Bitwarden
README 用 IMPORTANT 标记明确要求：使用 Vaultwarden 时，任何 bug 或建议都应直接反馈给 Vaultwarden 社区，而不是官方 Bitwarden 支持渠道。这意味着你无法从 Bitwarden 公司获得任何支持，所有问题都要依赖 GitHub issues、讨论区、Matrix 或 Discourse。对于企业用户，这可能是一个决定性因素，因为官方支持合同通常包含响应时间保证。另一个限制是，API 兼容性并非 100%，Bitwarden 客户端更新后可能短暂出现不兼容，直到 Vaultwarden 跟进。使用前应检查最新版本是否与你的客户端版本兼容。
替代方案对比：官方 Bitwarden 服务端与 Vaultwarden 的取舍
最直接的替代是 Bitwarden 官方自托管服务端。官方版本使用 .NET 技术栈，功能完整，与客户端同步更新，且有官方支持。但它的资源占用更高，部署更复杂，需要 SQL Server 数据库。Vaultwarden 用 Rust 和 SQLite（推测，README 未明说，但常见于该架构），资源占用低，部署简单，适合小型硬件。另一个替代是直接使用 Bitwarden 云服务，完全免运维，但数据不在自己手中，违背自托管初衷。选择的关键在于：你是否需要官方支持和最新功能，还是更看重资源效率和自主控制。Vaultwarden 的定位是后者，它牺牲了官方保障，换来了轻量。
编辑结论
Vaultwarden 适合那些希望完全掌控密码库数据、且不愿为官方 Bitwarden 服务端的高资源占用买单的个人或小团队。它不适合需要官方支持渠道、或依赖 Bitwarden 企业版特有功能（如某些高级策略）的用户。在采用前，务必确认你使用的客户端版本与 Vaultwarden 的 API 兼容性，并检查其 Wiki 中关于 HTTPS 和反向代理的配置要求，因为 Web Vault 在非安全上下文中无法工作。此外，由于项目遵循 AGPL-3.0，如果你修改并分发自己的实例，需要开源相应代码。最终判断：Vaultwarden 是一个功能覆盖率高、部署简单的自托管方案，但它的维护依赖社区，而非 Bitwarden 官方，因此生产环境中应定期关注其发布节奏和已知问题。
社区笔记