1Password又涨价了，于是我迁移到了自托管的Vaultwarden
内容提要
因1Password再次涨价，作者将个人密码库迁移至自托管Vaultwarden。过程包括用Docker和1Panel部署，配置DNS、证书与反向代理，通过安卓Bitwarden应用导入密码和通行密钥，整理261条记录，并强调备份需异地加密存储和定期恢复测试。作者认为Vaultwarden适合注重数据控制且愿承担运维的个人或家庭用户。
延伸解读
迁移的真正难点不在容器
文章指出，部署Vaultwarden容器本身并不复杂，真正耗时的是周边环节：DNS解析、证书管理、反向代理配置，以及通行密钥与普通登录项不同的迁移路径。作者在过程中曾因旧的IPv6记录导致请求未达新机器，也遇到过Mac本地DNS问题造成的访问失败。因此验收时不能只看容器健康状态，而要从公网HTTPS、重定向、健康端点和真实登录等多维度检查。
通行密钥迁移与客户端适配
作者强调，通行密钥的迁移路径与普通密码不同。本次迁移未使用.1pux或导出文件，而是通过安卓Bitwarden应用内的“从其他应用导入”功能，直接完成包括通行密钥在内的全部数据迁移。但浏览器扩展、桌面端和移动端都需要分别配置自托管服务器地址后才能登录。CLI工具也可能因安装方式或Node版本组合出现模块错误，需检查安装来源和运行时版本。
批量整理与版本冲突风险
迁移后整理261条记录时，作者仅修改文件夹归属，未改动密码、笔记或OTP，也未删除重复项。但在并发更新过程中，Vaultwarden出现版本竞争，导致6条同名Mattermost项目被暂时移入回收站。作者事后通过重新同步和逐条恢复，使项目ID与备份一致。这提醒我们：批量写入前必须做可恢复备份，单字段更新也是真实数据变更，并发请求未必更快，最终验证应对比总数、项目ID和回收站状态。
自托管意味着承担恢复责任
文章最后强调，自托管改变了问题的性质：用户需要自己负责恢复。作者的做法是：数据库、附件和配置存放在/data下，VPS定期备份，本地备份成功后再通过SSH同步到另一台主机DO_NEW，备份文件加密且可验证。同时，云账户、DNS、邮箱和VPS的恢复凭证不全部存放在该密码库中，并保留至少一条独立的应急路径。备份必须经过实际恢复测试才能信任。
Q&A
1Password涨价了多少？
1Password的家庭版（三人）年费从59.85美元涨到了71.88美元，涨幅约为20%。
为什么作者选择Vaultwarden而不是Passbolt或KeePassXC？
作者比较了三种方案：Vaultwarden轻量且Bitwarden客户端生态完整，适合个人或家庭；Passbolt团队权限和审计更强但部署更重；KeePassXC服务器信任面最小但本质是同步数据库文件，不适合实时多用户共享。作者已有VPS和1Panel，因此选择Vaultwarden。
迁移过程中如何导入密码和通行密钥？
作者没有使用.1pux或导出文件，而是在Bitwarden安卓应用中直接配置自托管服务器，然后通过“设置 → 保管库 → 导入项目 → 从其他应用导入 → 1Password”路径，一次性导入了常规数据和通行密钥。
自托管Vaultwarden时，哪些环节容易出问题？
容易出问题的环节包括：DNS解析（如旧IPv6记录导致请求未达新机器）、证书和反向代理配置（需统一管理避免冲突）、以及公开注册与邀请的分离设置（需正确配置SIGNUPS_ALLOWED和INVITATIONS_ALLOWED）。
作者在整理261条记录时遇到了什么教训？
批量更新文件夹时，由于并发更新导致版本竞争，6个同名Mattermost项目被暂时移入回收站。作者总结：批量写入前要备份，单字段更新也是数据变更，并发请求不一定更快，最终验证要对比总数、项目ID和回收站。
自托管后，备份策略应该怎么做？
备份不能只导出一个JSON文件。作者的做法是：数据库、附件和配置存放在/data下，VPS定期备份，本地备份成功后通过SSH同步到另一台主机DO_NEW，备份文件加密且可验证；恢复凭证不全部存放在该密码库中，并保留至少一条独立的应急路径。备份还需进行恢复测试。
迁移到Vaultwarden后，如何确认迁移真正完成？
作者认为需要满足四个条件：新设备能登录并自动填充；OTP和重要附件已抽样验证；通行密钥在目标客户端已验证或已有明确的逐站点重建计划；如果VPS消失，仍有独立的恢复路径和可验证的备份。
