Vaultwarden 保存的是密码库，部署时要把 HTTPS、备份和管理员入口当成硬要求。

\n
Vaultwarden 是我在 HomeLab 里最谨慎对待的服务之一。它体积小、部署简单，但保存的是登录凭据、密钥备注、二次验证恢复码这类高价值数据。对这种服务来说，“容器能启动”只是最低要求，真正要关心的是加密库是否可恢复、入口是否安全、管理员功能是否被保护。

先理解加密库边界

Vaultwarden 服务端保存的是加密后的密码库数据，主密码仍然由用户掌握。这个设计能降低服务端泄露后的直接风险，但不代表服务端就可以随便暴露或随便备份。攻击者拿到数据库后仍可能进行离线攻击，弱主密码、重复密码和泄露的备份都会放大风险。

因此我会把账号创建流程写清楚：关闭公开注册，只允许管理员按需创建；主密码要求足够强；重要账号开启二次验证；恢复码离线保存。服务端安全和用户习惯要一起管，不能只依赖“数据已经加密”这句话。

附件和组织共享也要克制。密码项越集中，恢复价值越高，泄露后的压力也越大。家庭成员共享条目时，我会定期清理不再需要的共享关系，并确认离线恢复码没有只保存在同一个密码库里。

设备授权也要定期看。旧手机、旧浏览器扩展、已经不用的桌面端如果还保留会话，等于给密码库留下额外入口。换设备或调整使用范围时，我会顺手清理会话并检查二次验证状态。

这一步适合放进季度安全复查。

复查完成后，只记录结果，不记录任何密码内容。

入口必须走受控 HTTPS

密码库入口不适合裸 HTTP。无论是浏览器登录、移动端同步，还是扩展连接，都应该走受控 HTTPS。反代里要确认 X-Forwarded-Proto、WebSocket、上传大小和超时设置，避免页面能打开但同步异常。证书过期提醒也要纳入监控，密码库入口坏掉会影响日常工作。

Compose 里我不会把 Vaultwarden 直接暴露成随处可访问的高权限端口。常见做法是只给反代所在 Docker 网络访问，宿主机端口按需绑定。管理员入口单独保护，不能和普通登录入口一样随意放在外面。

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "false"
      DOMAIN: "https://vault.example.com"
    volumes:
      - ./data:/data
    networks:
      - proxy

data 目录备份要能恢复登录

Vaultwarden 的 ./data:/data 是核心资产，里面包含数据库、附件、图标缓存和配置状态。备份不能只看文件存在，要定期在临时实例里恢复，确认账号能登录、密码项能打开、附件能读取、客户端能同步。恢复演练最好使用隔离域名或本地端口，避免误连生产实例。

备份文件本身也要加密保存。密码库数据即使服务端加密，也不适合明文散落在多个备份盘或云同步目录里。备份记录里写清生成时间、镜像版本、文件大小、校验值和恢复命令，不记录主密码、管理员令牌或敏感账号。

管理员入口保护到位

Vaultwarden 的管理页面很方便，但也很危险。管理员令牌不能写在公开文档、聊天记录或可同步的普通笔记里；如果不需要长期使用，宁愿关闭管理入口。必须保留时，要放在受控访问范围内，并给反代加额外认证或来源限制。

公开注册默认关闭，邀请也要有明确流程。家庭成员离开使用范围时，账号停用、设备会话清理、二次验证状态都要检查。密码库不是普通小服务，账号生命周期要当作安全流程维护。

升级前后看数据和客户端

升级 Vaultwarden 前，我会先备份 data 目录，记录当前镜像版本和关键环境变量。升级后不只看 Web 页面，还要测试浏览器扩展、手机 App、桌面客户端同步。很多问题只在客户端同步时出现，页面登录成功并不能代表整个服务正常。

Vaultwarden 的部署目标不是追求功能多，而是可靠、安全、可恢复。关闭公开注册、强制 HTTPS、保护管理员入口、加密备份并做恢复演练，这些工作听起来不花哨，却决定密码库能不能放心长期使用。对于密码服务，少一点随意，多一点流程，是值得的。