自建的风险与责任

先把丑话说在前面

任何自建教程都会热情洋溢地讲掌控感和免费，但负责任的做法是先把风险讲清楚。自建密码管理器不是请个保姆，是把保险柜搬回自己家——你既是用户也是运维，出了任何问题第一责任人都只有你自己。这句话不是吓唬人，而是后面所有章节成立的前提。

这本书不会回避这些风险，反而会在后面的章节里逐条给出应对办法，每一条都有对应的操作章节兜底。但在动手之前，你需要先接受三件事：服务可能宕，安全自己守，维护一直做。接受了这三条再往下走，自建之路才走得踏实。

风险一：服务挂了，全家的密码都拿不到

这是最直观的风险。托管服务的背后有专业团队保证可用性，多机房、多备份、有监控告警；而你家的服务器没有这些待遇。断电、断网、硬盘损坏、系统更新出问题，任何一样都会让密码服务下线。如果手机上的客户端还没缓存过密码库，家人就会面临取不到密码的窘境，路由器登不上、NAS 进不去、连 Wi-Fi 密码都要翻箱倒柜找当初的设置记录。

应对思路有两条：硬件层面保证常开与稳定，软件层面做好备份。一台低功耗小主机加 UPS 兜底，加上定期的冷备份，能把这件事的风险压到可接受的范围。具体的方案设计在备份章节和宕机自救章节展开。

换个角度看，宕机风险其实没有想象中那么可怕。首先是频率低：一台稳定的小主机半年不出一次故障很正常。其次是影响有限：已经登录过账号的客户端有本地缓存，密码依然能查看，只是改不了、同步不了。真正让你无密码可用的场景同时需要满足「服务挂了」和「所有设备都没缓存」两个条件，而第二条件是可以主动避免的——只要在每个常用设备上登录过一次。把最坏情况拆开看，必要性反而清楚了。

风险二：安全责任完全在你

托管服务被攻击时，有安全团队在一线处置。自建服务被攻击时，处置的人是你。你必须自己面对暴露在公网上的风险：弱密码的管理后台、没更新的组件、过时的加密配置，任何一个都可能变成突破口。没有人会在凌晨三点打电话通知你服务器正在被扫。

好消息是零知识架构给了你很强的底线：即使数据库被拖走，主密码足够强时攻击者依然解不开。坏消息是你不能因此放松排场，安全加固清单章节会给出可执行的检查项，从关闭注册到限制访问来源逐步收紧。自建安全的原则是层层设防，让零知识架构成为最后一道防线而非唯一一道。

负责网络安全与运维是件需要长期投入的事，好消息是密码服务的加固清单并不长，一次性配好后维护量很小。网络入口那部分可以交给家里的软路由，参考《软路由指南》把防火墙规则收紧一层，服务这边的加固只需要按清单走一遍。

具体到攻击面，有三类是他人在公开网络环境下最常见的试探方式：扫描公网开放端口的自动化机器人、针对管理后台的密码字典爆破、利用旧版本已知漏洞的定向攻击。这三类攻击都不需要针对你个人，每天在公网上自动发生着。对应的处置都不复杂：只开放需要的端口、给后台加访问限制、保持版本更新。这几条在安全加固清单章节会写成可勾选的条目，逐条打勾即可。

一个稍微反常识的判断：自建密码服务在安全上反而有一个天然优势——目标小。攻击大规模托管服务的收益是一次性拿到几千万条数据，值得投入专业人力；攻击你家用的一台小服务器，最理想的战果也只是几条家庭密码，投入产出比极低。这不构成放松警惕的理由，但确实让风险评估可以回归常识：做好基础加固，剩下的不必过度焦虑。

说完风险，也公平地列出对应的收益，这样决策才不失偏颇：

把这张表贴在部署完成后的第一时间，你会发现自己换来的是一份长期的家业。说到底，自建的本质是用确定性换不确定：维护时间是你能确定的投入，而外部服务的变数是你无法确定的风险。愿意做这笔交换的人，通常也不愿意把钥匙交给陌生人。如果你看到这里还愿意继续，那这本书剩下的章节就是为你写的：部署、备份、使用、加固，每一步都给你铺好路。已经把硬件和网络条件准备好的读者，可以直接翻到下一章，那里有完整的 Docker 部署步骤在等着；还没准备好的读者，先回上一章把选型和设备两件事定下来。

风险三：维护是长期的

自建不是一劳永逸。Vaultwarden 会更新，依赖的容器运行时会更新，客户端会随之升级，HTTPS 证书需要续期。这些事情不难，但需要你把「定期看一眼」变成习惯。每年花在维护上的时间可能只有几个小时，但这几个小时不能省，拖上半年的服务往往就是这样拖出事的。

维护清单其实很短：关注项目的新版本通告、确认证书自动续期还在工作、检查备份确实能恢复。养成每月花十分钟扫一眼的习惯，这个小服务的稳定性会超过你的预期。

一个让你坚持下去的技巧：把维护这件事固化成日历提醒。人脑不擅长记住「每季度该检查一次备份」这类周期性任务，与其依靠自觉，不如让日历每月准时提醒你一次。点开服务页面看两眼，顺手就完成了。

什么情况下不该自建

清楚自己不适合，同样是一种成熟。以下几种情况建议选择托管方案：

对照这张表诚实地给自己打分。如果四条里命中两条以上，先回到上一章的对比表，1Password 或 Bitwarden 官方云可能是更合适的选择。承认不适合不丢人，把时间花在自己擅长的地方才是正事，密码管理这件事最重要的是开始用，而不是用哪一种。

还有一个容易自我说服的误区值得警惕。有人会想「先随便部署在旧笔记本上试试」，结果笔记本合盖就休眠，家人用的时候十次有八次连不上，最后结论变成「自建不靠谱」。工具没错，是前提条件没满足。要么满足条件再开始，要么直接选托管方案，不要在中间地带长期停留。

另一个方向的误区同样常见：过度工程化。刚入门时容易热血上头，给密码服务配独立虚拟机、买专门域名、上复杂的高可用方案，半年后热情退潮，维护变成负担，方案反而比简单部署更容易失效。能用一个容器解决的事就别用三个。本书会给出一个刚好够用、足够稳的方案形态，把多余精力留给真正重要的部分，比如备份和加固，它们才是决定这门服务能不能跑五年的关键。

责任的另一面是自由

把风险讲完，也该说说为什么依然值得做。自建最大的收益不是省钱，是你终于完全拥有自己的数据。没有服务条款的突然变更，没有订阅涨价，没有公司被收购后的不确定性，你的密码库不会因为某家公司的战略调整而消失。你付出的运维时间，换来的是对数字身份的彻底掌控。

这种掌控需要的知识并不冷门——Docker 基础、HTTPS 配置、备份习惯，都是自建生态里反复用到的通用技能。如果你已经跟着《NAS DIY 指南》或《Synology DSM 指南》跑过其他服务，再加一个 Vaultwarden 顺手得很。风险可控、收益明确、技能可复用，这是自建值得投入的理由，也是为什么我们愿意花一本书的篇幅把它讲透。

想通这一点之后，剩下的就是具体操作。这本书的责任是让操作部分尽量平顺，让风险都有对应的预案，让你在凌晨突然想起来「密码服务器还在跑吗」的时候，答案是放心的。

最后给一个心态上的建议。自建这件事最容易在两个时刻翻车：刚部署成功那阵子热情高涨，恨不得把所有服务都搬来自建；以及第一次遇到故障时备受打击，怀疑自己是不是选错了路。正确的位置在两者之间——把它当作一个需要定期照看的小工具，像养护一盆植物，而不是一个需要时刻盯着的工程。热情会退，习惯会长存，能长期跑下去的服务才是好服务，慢一点反而走得远。

这本书的立场到这里也就清楚了：把风险讲在前面，不是为了劝退，是为了让你带着预期出发。接受责任的人，才配得上自由。剩下的章节我们进入正题，从 Docker 部署开始，一步一步把这套密码方案搭起来。路已经指好，灯也都点上了，剩下的就是迈出第一步。

延伸阅读

• NAS DIY 指南：从硬件层面降低服务掉线的概率
• Synology DSM 指南：利用群晖的备份工具实现定期冷备份
• 软路由指南：在网络入口处做访问控制