Vaultwarden 自建密码库：部署、TLS 与不会丢的备份

为什么是它，不是官方服务

Bitwarden 官方提供托管，但很多人希望密码库在自己的机器上。Vaultwarden 是 Bitwarden 服务端的兼容实现，用 Rust 写，单容器、SQLite 就能跑。项目 69,498 star，AGPL-3.0，当前版本 1.37.4。

它的兼容性做得足够好：官方桌面端、移动端、浏览器扩展都能连，填服务器地址即可。这意味着你不需要迁移客户端，只需要迁移服务端。

一份能用的 compose

services:
  vaultwarden:
    image: vaultwarden/server:1.37.4
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"
      ADMIN_TOKEN: "用 argon2 生成的哈希"
      TZ: "Asia/Shanghai"
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"

三个参数值得解释：DOMAIN 必须和实际访问地址完全一致，否则附件、邀请链接会出错；SIGNUPS_ALLOWED 建完自己的账号就关掉；ADMIN_TOKEN 不要用明文，用 argon2 命令行生成哈希再填。

TLS 不是可选项

Bitwarden 客户端依赖 WebCrypto，而 WebCrypto 只在安全上下文（HTTPS 或 localhost）里可用。用 HTTP 暴露出去，客户端会直接报错，或者某些功能静默失效。

所以我把它绑在 127.0.0.1，由反向代理终止 TLS。Caddy 三行就够；用 Nginx 记得转发 X-Forwarded-Proto，并把请求体上限调大——附件上传会超过默认的 1MB。

备份：别直接 cp 数据库

SQLite 在写入过程中直接复制，可能拿到一个损坏或缺少最新事务的文件。正确做法是用 SQLite 自己的备份命令：

docker exec vaultwarden sqlite3 /data/db.sqlite3 ".backup '/data/backup.sqlite3'"

需要备份的不止数据库：attachments/（附件）、sends/（临时分享）、rsa_key*（加密密钥）都要一起带走。少了 rsa_key，恢复出来的库解不开。

备完做一次恢复演练：起一个新容器，挂上备份目录，登录、打开一条带附件的条目。没验证过的备份不算备份。

日常维护的几件事

• 升级前看 release notes，跨大版本先备份；
• 定期跑 /admin 看用户与邀请状态；
• 开启失败登录限速，公网暴露的密码库是重点目标；
• 手机端也配上，否则主密码只存在脑子里，出事没法查。

我的判断

自建密码库的收益很直接：数据在自己手里，没有订阅费，客户端体验和官方一致。风险也很直接：这台机器一旦挂掉且备份不可用，你所有的密码就都没了。

所以它的优先级排序应该是：备份 > TLS > 加固 > 功能。顺序反了，早晚出事。

参考来源

• Vaultwarden

延伸阅读

• 反向代理的三个原生参数
• 值得自建的 8 个开源项目