Bitwarden 与 Vaultwarden 的关系

先有 Bitwarden，后有 Vaultwarden

Bitwarden 是一家公司的名字，也是一个开源密码管理器产品的名字。它有两部分：客户端（浏览器插件、手机 App、桌面程序）和服务端。2018 年 Bitwarden 把服务端代码开源，任何人都可以审查它到底怎么处理你的密码。这在密码管理行业里是不多见的做法，因为大多数同类产品只开放客户端，服务端是个黑盒。

但官方服务端有个现实问题：它是用 .NET 写的，部署起来偏重，需要不少内存和组件，对机器配置有不低的要求，对只想在家里跑个小服务的个人用户并不友好。普通家庭用户为了一个密码服务去配置一套完整的运行环境，怎么看都有点杀鸡用牛刀。

于是社区出现了 Vaultwarden。它最早叫 bitwarden_rs，后来改名 Vaultwarden，是一个用 Rust 重写的轻量 Bitwarden 兼容服务端。它的核心卖点是：内存占用极小，一台旧电脑、一个 NAS、甚至一个树莓派都能轻松跑起来。Rust 语言在系统级软件里以省内存著称，这也是为什么同样的功能它只需要官方服务端一小部分的资源。如果你读过《NAS DIY 指南》，应该知道这类小机器最适合常驻运行这种小而稳的服务，Vaultwarden 几乎是为它们量身定做的。

部署形态上，Vaultwarden 官方提供独立的可执行文件，也有现成的容器镜像。绝大多数自建玩家选择容器方式部署，因为它把环境依赖打包在一起，一条命令就能拉起来，升级时换个镜像标签即可。下一章会给出具体的 Docker 部署步骤，这里只需建立一个印象：这不是一个需要专门购置硬件才能跑的服务，你手边的主力设备足够了。

和官方服务端的关系也可以这样理解：它们是同一份协议的两个实现。你的密码库在这两个服务端之间是可以迁移的，导出再导入即可，不会因为选了 Vaultwarden 就被锁死在这条路线上。将来若有一天你决定换回官方云或者搬家到另一台机器，数据始终是你的。

对擅长读代码的读者还有一条额外的定心丸：Vaultwarden 的源代码完全公开，任何人都能审查它对协议的实现是否忠实。事实上社区确实有人这么做，历史版本里被发现的问题都得到了修复。开源不是万灵药，但在这个场景里它把「相信实现」变成了「可以验证实现」。

至此可以给本章一个总结了：Vaultwarden 是一个把 Bitwarden 协议轻量化的独立实现，用官方客户端、连自家服务器、存自家数据。记住这句话，接下来每一章的操作都会顺理成章。

兼容关系：客户端是官方的，服务端是自己的

这是最容易被新人误解的一点。Vaultwarden 不是 Bitwarden 的「简化客户端」，也不是一个需要专用 App 的独立产品，更不是什么第三方魔改版本。它实现的是 Bitwarden 的服务端 API 协议，是协议层面的兼容。

换句话说，你在手机上装一个官方 Bitwarden App，登录时把服务器地址指向家里的 Vaultwarden，剩下的体验和用官方服务几乎没有区别。家人不需要知道什么是自建，他们看到的只是一个普通的密码 App。这也是 Vaultwarden 能被广泛信任的原因：客户端代码是官方的，加密协议是官方的，你只是换了一台存放数据的服务器。

兼容性的另一个好处是客户端更新与你无关。Vaultwarden 追赶的是协议而不是客户端版本，官方客户端照常升级，你的密码库照常用。这种架构决定了自建者的精力主要花在服务端这一小圈地方。

为什么改名

Vaultwarden 原名 bitwarden_rs，名字里的 rs 指 Rust。改名发生在 2021 年，主要有两个原因：

一是避免商标混淆。带 bitwarden 字样的名字容易让人以为它是 Bitwarden 官方维护的项目，实际上它是独立的社区项目，官方并不背书，也不会为它负责。万一某天它出了问题，背锅的很可能是 Bitwarden 公司，这对双方都不公平。

二是项目定位早已超出「重写」的范畴。它在兼容协议之外发展出了自己的管理后台、自己的配置方式、自己的文档体系，是一个独立运转的软件，需要一个独立身份。改名是社区成熟的标志。

理解这段历史很重要，因为你会在各种教程里同时看到两个名字，老文章里写的是 bitwarden_rs，新教程里写的是 Vaultwarden。它们指的是同一个软件，新部署一律用 Vaultwarden 这个名字，遇到旧教程心里有数即可。

协议兼容意味着什么

多说一点「协议兼容」这件事，因为它是整个方案的支点。Bitwarden 的客户端和服务端之间通过一套公开的 HTTP API 通信，包括登录、同步密码库、上传附件、注册两步验证等接口。Vaultwarden 把这套接口实现了一遍，行为和官方服务端一致。

所以在客户端眼里，你的家用小服务器和 Bitwarden 官方的服务器集群没有区别。服务器是哪个实现的、跑在什么硬件上、由谁维护，客户端一概不关心，它只认协议。这种基于协议的兼容比基于代码的移植更稳固，因为只要协议不变，双方可以独立演进。

这也是为什么敢把家人托付给这套方案：他们用的就是官方 App，所有上手教程、界面截图都能对得上。自建的复杂性藏在服务端，对使用者完全透明。

谁在维护，可靠性怎么样

Vaultwarden 是社区驱动的开源项目，托管在代码托管平台上，由志愿者维护。这带来两个必须正视的事实：

第一，它没有商业公司的客服和 SLA，出问题要在社区里找答案，没人承诺几小时内响应。好消息是社区非常活跃，常见问题几乎都有现成的解决方案，从部署到踩坑的记录都齐全，遇到困难时通常搜一下就能找到思路。

第二，它的更新频率不低，每个版本都会同步兼容官方客户端的新变化、修复发现的安全问题。这既是好事（协议始终保持兼容），也意味着运维者需要定期升级，不能部署完就丢在脑后。升级的具体做法在后面的升级章节会详细讲。

对应的运维思路可以参考《软路由指南》里对开源固件的态度：用社区作品享受自由与透明，同时承担起自我维护的责任。开源社区不提供保姆，但把选择权和知情权交给了你。

一个实用的建议是：部署前花十分钟浏览项目的发布说明，了解当前版本的已知问题。社区项目通常会把重要改动和注意事项写得很清楚，这十分钟往往能省掉后面几个小时的排障。另外关注一下当前版本的发布日期，太久没更新的版本可能跟不上客户端的变化。

最后明确一点：Vaultwarden 与 Bitwarden 官方没有隶属关系，也不要把它理解成官方的轻量版。它是社区按公开协议实现的独立软件，遇到问题去 Vaultwarden 的社区求助，而不是找 Bitwarden 官方客服，后者帮不上忙。分清这个边界，排障时才不会走弯路。

适合什么人

自我评估的关键就两条：有没有一台常开的小机器，愿不愿意花一两个小时把 HTTPS 配好。两者都满足，这条路会比想象中顺畅很多；有一条不满足，建议再想想或者先补齐条件。自建的成败往往不取决于技术水平，取决于这两个前提是否扎实。

延伸阅读

• NAS DIY 指南：为 Vaultwarden 提供一台常开的低功耗主机
• OpenWrt 基础：从路由器层面理解家庭网络的访问入口