密码存进浏览器以后，换一个浏览器或给手机配置应用，往往又需要找一遍。一个独立密码库能把条目与设备分开管理；自托管则把服务器、更新和备份的责任也交给了维护者。
Vaultwarden 适合愿意承担这些维护工作的人。部署成功的判断不能停在登录页：浏览器扩展和手机要能同步，注册入口应受到控制，丢失服务器后还要能恢复。若这些工作暂时没有人负责，已有的密码管理服务可能更适合继续使用。
它是什么服务，哪些东西需要自己负责
Vaultwarden是兼容 Bitwarden 客户端 API 的独立服务端实现，不是 Bitwarden 官方服务端的轻量配置。客户端兼容性要按双方版本核对，不能因为某个功能在官方云端可用，就直接推断自托管实例完全一致。
服务端保存密码库数据并提供同步，使用者管理主密码与第二因素。服务器登录密码、Vaultwarden 管理后台凭据和个人密码库的主密码是不同层次，不能混为一个账户。
首先安排两份恢复资产：服务器数据的备份，以及个人主密码和双重验证恢复信息的受控保存。备份文件不能替你记住主密码；恢复码只放在同一个无法登录的密码库里，也会形成依赖循环。
初次试用用虚构条目。客户端、邮箱、备份和恢复验证完整之前，不需要急着把所有重要密码一次性搬过去。
部署从私人端口开始
VPS 已安装 Docker Engine 与 Compose。为应用准备独立目录，不与博客上传目录混用：
mkdir -p ~/vaultwarden/vw-data
cd ~/vaultwarden
保存以下 compose.yaml，把域名替换成自己的公开 HTTPS 地址：
services:
vaultwarden:
image: vaultwarden/server:latest
ports:
- "127.0.0.1:8000:80"
environment:
DOMAIN: https://vault.example.com
SIGNUPS_ALLOWED: "false"
volumes:
- ./vw-data:/data
restart: unless-stopped
配置以官方 Compose 文档为基础，增加了注册限制。latest 便于初次选择镜像，正式迁入密码后应固定验证过的版本或摘要，关注项目更新，而不是让无人值守的自动更新直接修改关键数据。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 vaultwarden
宿主机回环端口不会直接接受公网连接。后续用反向代理提供 HTTPS，DOMAIN 与实际访问地址保持一致。网站证书、客户端服务地址和邮件里的链接都要检查，不只确认首页返回200。
HTTPS 是客户端正常工作的条件
Web 密码库使用浏览器的 Web Crypto API，需要安全上下文。项目使用说明明确要求正确配置 HTTPS。公网 HTTP 地址出现异常时，应修正域名与证书，不要引导用户在浏览器关闭安全保护。
已有 Caddy 可以把独立域名代理到本机8000端口：
vault.example.com {
reverse_proxy 127.0.0.1:8000
}
使用其他代理时，按照当前代理示例处理头部和连接。不要将旧文章里额外的 WebSocket 端口映射不加核对地带到当前版本。
首次创建个人账号需要一个受控窗口。可以先通过私人网络或临时限制公网访问，将 SIGNUPS_ALLOWED 改为 "true"，重新创建容器，完成自己的注册，然后立即改回 "false" 并再次应用配置。不要在开放注册的状态下放着实例等待“以后再配置”。
关闭注册以后，用无登录状态验证不能自由创建新账户。注册限制文档也说明，组织邀请有自己的控制规则。个人注册关闭，不等于所有邀请方式都被关闭。
先连接两个客户端，确认同步方向
在浏览器扩展中选择自托管服务器，填入自己的 HTTPS 地址，再登录测试账户。手机客户端也设置相同服务端。服务器地址设置的位置随客户端版本可能变化，按当前客户端说明操作，不要只输入用户名后期待它自动找到自托管服务。
用浏览器新增一条虚构登录信息，手机手动同步后确认出现；再在手机修改备注，回到浏览器同步核对。这样能验证双方确实连接同一实例，而不是手机仍登录官方云端。
同步和解锁不同。客户端能解锁已有缓存，不能证明服务器现在可访问，也不能证明刚才的修改已上传。测试时核对新增条目、修改时间和同步错误，而不是只看客户端可以打开。
迁移旧密码库时，先用小样本导入，检查网址、用户名、备注和多网址字段，再处理完整数据。导出文件可能含明文敏感内容，应放在受限位置，用完按既定流程清理；不要把文件上传到公开网盘，或在排障消息中贴完整内容。
双重验证和邮箱要各自测试
为正式账户启用适合自己的第二因素，保存恢复信息，并用一台未登录的设备实际完成一次登录。不要只看到设置页显示已启用，就删除原来的恢复途径。
邮件设置影响验证、邀请和部分恢复流程。SMTP 服务、发件地址与域名认证按发送渠道要求安排。发出一封测试邮件，再核对收到的链接是否指向正确域名。邮箱功能未配置完整时，应明确哪些账户操作不能依赖它。
管理后台不是普通密码库的首页。确实需要启用时，按官方管理文档设置独立凭据和访问限制，不要与个人主密码共用。后台保存的配置可能写入 config.json，以后修改环境变量时需核对实际生效来源，避免看着 Compose 以为参数已经改变。
共享密码也不应靠所有人登录同一个个人账号实现。需要组织或集合时，先建立测试共享，验证成员只能看到应当共享的条目，再迁入正式数据。成员离开后检查组织权限、客户端会话和实际访问，不要只删除一条联系人记录。
备份整个状态，不只备份一个数据库文件
默认 SQLite 部署中，数据目录包含数据库、附件、签名密钥及其他状态。备份文档区分数据库文件与附件，提供在线数据库备份方式。运行中只复制 db.sqlite3，可能忽略对应 WAL，不能当成一致备份。
对小规模个人实例，维护窗口停止应用，再归档完整 vw-data 是容易理解的离线办法：
umask 077
docker compose stop vaultwarden
tar -czf vaultwarden-data.tar.gz vw-data
docker compose start vaultwarden
检查归档是否成功，再复制到独立、加密且受限的备份位置，保存部署配置和镜像版本。即使密码库里的条目经过加密，备份仍含账户和服务状态，不能当成普通公开文件。
定时自动备份需要处理失败路径，停止成功却备份失败时，要能恢复服务并告警。备份策略稳定前，不宜只把上面三行塞进 cron 后长期不检查。
账户丢失与服务器丢失，不是同一种恢复
VPS 损坏时，可以凭服务器备份重建服务，再用自己的账户解锁密码库。忘记个人主密码时，恢复服务器并不会消除密码库的加密条件。两类情况要分别安排，不能只在安装笔记中写一句“有备份就能找回”。
第二因素设备损坏时，也应使用预先保管的恢复方式，而不是先删除服务器数据。恢复信息最好在受控的独立位置保存，能在手机和电脑同时不可用时拿到。决定存放位置时考虑谁有权使用，避免从可恢复变成所有人都能绕过登录。
客户端有本地数据不等于它是一份完整服务端备份。账号、组织、附件、共享权限和其他状态可能涉及不同保存方式。长期离线的客户端也可能不是最新版本；把它重新连接到正式实例前，应理解同步方向，避免用一次未知状态的修改干扰恢复。
服务器迁移以后，旧客户端仍可能保存旧地址或会话。先让测试设备连接新环境，确认新增与修改可以往返，再逐台切换。不要让新旧服务同时对外承接真实编辑，之后才尝试合并两边不同的数据。
出现“浏览器能登录，手机仍同步失败”时，核对完整服务地址、证书和客户端错误信息。再用测试条目确认同步，不需要向第三方提供真实密码或令牌。请求帮助时只分享排障必需的版本、状态和去敏日志。
换服务器时先恢复，再切域名
恢复演练使用隔离实例和测试域名，避免两个服务端同时承接真实客户端修改。确认数据目录、数据库与附件来自同一份一致备份，再启动对应版本。
登录测试账号，检查条目、附件和同步。启用了第二因素时也验证相应登录路径。单纯看到数据库文件大小正常，不能代替客户端验证。
演练完成后记录恢复需要哪些配置、备份和凭据，以及这些材料由谁保管。真的遇到 VPS 损坏时，不应还依赖那台机器上唯一的一份安装笔记。
日常维护可围绕三个动作安排：关注安全更新，在升级前保存一致备份，定期检查客户端同步和恢复能力。自托管密码库的价值在于一套可控制、可恢复的使用流程；服务器上的绿色运行状态只是其中一项。