Vaultwarden 与 Bitwarden:自建方案怎么选

上一篇我们定下了自建路线，这一篇要解决一个几乎所有人都会卡住的问题：同样号称可以自建的 Bitwarden 系，到底装哪一个？仓库里搜出来的项目名字长得像亲兄弟，官方文档和社区教程却各说各话。这篇先把两者的关系讲透，再从资源占用、功能完整度、部署难度和维护成本四个方面对比，最后告诉你本书为什么全程围绕 Vaultwarden 展开。看完这篇，你应该能在五分钟内确定自己要装哪个服务端。

先把关系讲清楚：客户端和服务端是两回事

很多人以为 Bitwarden 是一个软件，其实它是一套架构。Bitwarden 的客户端——也就是你手机上的 App、电脑上的程序、浏览器里的插件——是独立的；客户端背后要连一个服务端，负责保管加密后的保险库、在设备之间同步。Bitwarden 官方提供两种服务端：一种是官方云，你注册账号即用；另一种是官方自托管方案，面向企业，把整套服务端软件自己跑在服务器上。

Vaultwarden 则是社区用 Rust 重写的一个轻量服务端实现。它没有照搬官方那套庞大的组件，而是瞄准了同一个接口协议：只要客户端按官方协议说话，Vaultwarden 就能应答。结果就是你依然下载官方的 Bitwarden 客户端，依然按月版本号迭代(比如 2026.7.0 这样的发布节奏)，在客户端的服务器地址里填上你自己的域名，体验和连官方云几乎没有差别。换句话说，Vaultwarden 不是另一个密码管理器，它是 Bitwarden 官方客户端的一个自建服务端选项。

这个架构带来一个很实际的好处：你不会被锁死在某个生态里。哪天 Vaultwarden 出问题，你可以把数据导出，迁到官方自托管或者迁回官方云，客户端配置改一行地址就行。密码管理这种要用很多年的工具，可迁移性比任何花哨功能都重要。反过来，如果你用的是某个封闭生态的密码工具，客户端和服务端绑死在一家厂商手里，迁移才是真正的大工程。

也要澄清一个常见的误会：Vaultwarden 不等于“盗版 Bitwarden”。它是独立的开源项目，作者和社区在维护，代码完全公开；它只是兼容了官方客户端的接口。你的加密数据始终端到端掌握在自己手里，服务端看到的只是密文，这和连官方云时的加密模型是一致的——主密码派生的密钥从来不会上传。理解这一点之后，你就不会再纠结”用社区实现会不会被官方封杀“:客户端与服务端走的是公开接口，服务端换哪家，客户端照连不误。

官方自托管 vs Vaultwarden:差在哪

Bitwarden 官方自托管方案的定位是企业。它由多个组件组成：主程序、数据库、缓存、任务处理、计费模块，需要 PostgreSQL、Redis 这些依赖，默认就要几 GB 内存才能跑顺。功能上它是最全的：组织共享、企业登录、目录同步、审计日志，这些面向团队的能力一应俱全。但代价也很明显：一台家用小机器根本扛不动，部署像在搭一套小型企业系统，升级也是一整套组件联动，出问题时排障范围要在多个组件之间跳。

Vaultwarden 走的是完全相反的路线。它是开源免费的，单个容器搞定一切——官方镜像 vaultwarden/server，数据落在容器内的 /data 目录，容器内只开一个 80 端口，宿主机上映射成 8080:80 之类的端口就能用。资源占用低得惊人：几百 MB 内存，甚至 N100 小主机、树莓派级别的设备都跑得很轻松。功能上覆盖了个人使用的绝大部分场景：保险库、自动填充、TOTP 验证码生成、附件、组织共享给几个家人朋友用也够。

当然 Vaultwarden 也有它的边界。一些企业级能力它不做也不打算做：高级组织策略、单点登录、目录同步这些，如果你是为公司搭一套全员密码平台，官方方案才是对的选择。对个人用户来说，这些功能一辈子也用不上，却要为它们多付出几倍的资源和维护成本，完全不划算。换个说法：Vaultwarden 砍掉的是企业包袱，保留的是个人刚需，这种取舍对家庭用户是正中靶心。

实际部署是什么感觉

说几个具体数字，帮你建立直观感受。本书示例部署用 Docker 或 Docker Compose 完成，镜像直接固定到 vaultwarden/server:1.37.4 这个稳定标签。一条命令把容器拉起来，数据目录挂到宿主机，保险库、附件、日志全都落在同一个 /data 映射出来的目录里，备份就是拷这个目录。容器内部默认监听 80，你在宿主机上映射成 8080:80，前面再架一层反向代理——Caddy、Nginx 或者 Nginx Proxy Manager 都行——由反代负责 HTTPS 证书和对外端口。整个过程在一台有 Docker 环境的机器上，熟练的人半小时内可以跑通。

反向代理这一层为什么不能省？因为 Vaultwarden 容器本身只提供明文 HTTP，手机和浏览器客户端走明文连接是不可接受的。HTTPS 证书由反代自动签发和续期，容器只管业务，这是 Docker 部署的常规分工。这些细节我们在第 3 章会一步步带着做，这里你只需要知道：自建的复杂度被控制在一个容器加一层反代，而不是一整套企业系统。升级的时候更能体会差别：官方自托管要依次更新数据库、各组件、调度任务；Vaultwarden 只是拉取新标签的镜像，重建容器，服务几乎无感。

从数据模型看，你为什么可以放心把它跑在自己设备上

很多人自建之前有个隐忧：服务端跑在自己家里，是不是意味着我要对加密算法负责？其实不用。整个加密模型的关键动作发生在客户端：你输入主密码之后，客户端在本地用主密码派生出加密密钥，所有条目在本地加密完成，之后才把密文发给服务端。服务端从头到尾看到的都是密文——就算服务器被人拖库，拖走的也只是一堆解不开的密文。

这意味着两件事。第一，你的安全边界收敛到两个点：主密码的强度，和设备本身的安全。主密码够长够复杂，暴力破解在工程上就不可行；设备不被人随便登录，密钥就不会泄露。第二，你不需要理解任何加密实现细节，Vaultwarden 只是个忠实的密文保管员，这和连官方云时的模型完全一致——你没有把安全责任放大，只是把保管员从厂商换成了自己。

Vaultwarden 还有一个对个人很友好的细节：它默认不限制保险库条目数量和附件总量。商业云的免费档往往限制条目数和设备数，付费档按人头计费；自建之后，你的硬盘有多大，附件就能放多少，条目想存多少存多少，这对把所有证件扫描件也塞进保险库的人来说很实用。

个人用得上哪些，企业用得上哪些

把功能按人群拆开，取舍会更清楚。个人日常高频用到的是这些：多设备自动同步、浏览器插件自动填充、手机端指纹解锁、TOTP 验证码生成、附件存储、紧急访问。这些 Vaultwarden 全部开箱支持，和官方云体验一致。个人偶尔用到的：组织共享给一两个家人，Vaultwarden 也能胜任，只是管理界面没有企业版那么花哨。

企业才用得上的则是另一套：组织级权限策略、单点登录、目录服务同步、审计日志、多域管理。这些功能背后是额外的数据库、缓存和调度组件，家用机器跑不动也没必要跑。判断标准很简单：你能不能说出一个自己会用到这些功能的具体场景？说不出来，它们对你就是负资产——占资源、增加升级复杂度、扩大攻击面。

本书为什么选 Vaultwarden

理由有三条，而且条条对应你已经知道的约束。第一，读者手里的设备大多是旧电脑、小主机或者家用 NAS，内存和 CPU 都不宽裕，Vaultwarden 的资源占用让这类设备跑得动，官方自托管则会直接劝退。第二，本书的目标读者是个人和家庭使用，不是企业 IT 部门，Vaultwarden 的功能面恰好覆盖个人全部需求，没有为用不上的企业功能买单。第三，维护成本是长期账：单容器升级就是换个镜像标签，备份就是拷一个目录，出问题时排查范围小，这些对一个人维护的服务来说至关重要。

也要说清楚一件事：选 Vaultwarden 不是因为它“更高级”,而是因为它更合身。它同样连着官方客户端，同样支持所有主流平台，你的使用习惯和用官方云没有任何差别。你放弃的只是那些企业级组织功能——对个人来说，那叫卸包袱，不叫缩水。生态上你也完全不吃亏：官方客户端持续按月更新，浏览器插件、手机自动填充、TOTP 这些日常能力都是一等公民，而不是社区凑出来的半成品。最后再强调一遍选择顺序：先定自建路线，再定服务端；服务端只在官方自托管和 Vaultwarden 之间二选一，本书的结论是后者。接下来的篇幅，除非特别说明，凡是说”部署“的地方，指的都是 Vaultwarden。

延伸阅读

• 服务端要跑在一台长期在线的设备上，硬件怎么挑先看 家用 NAS 选购与上手指南，低功耗小主机和旧电脑的取舍那里讲得很细。
• 如果你打算把它和其他家庭服务跑在同一台机器上，系统规划参考 家用 NAS 家庭服务器搭建指南 的系统与服务规划部分。
• 装之前如果还在犹豫“我到底要不要服务器”,下一篇 KeePass 那篇会把本地文件方案讲透，两者定位差异一次理清。
• 下一篇：KeePass 与本地文件方案够用吗。