把密码交给自己：自建与云服务的本质区别

读到这里，你已经明白为什么需要密码管理、密码管理器能干什么了。本章最后一篇，要回答那个绕不开的问题：这个装着你全部密码的保险库，到底放在谁家的服务器上？是交给一家成熟的云服务商省心，还是自己动手搭一套、把数据彻底收回来？这不是一个「哪个更好」的偏好问题，而是一个关于「数据归属、密钥归属、责任归属」的本质选择。想清楚它，你才知道这本书后面讲的自建，到底是为了什么，又要付出什么。

第一个分叉：数据存在谁那里

市面上的密码管理器，按「保险库托管方」划分，大致就是两类。

一类是云服务模式：你注册账号后，保险库数据加密后存放在服务商的服务器上，你在任何设备登录，都从云端拉取同步。它的好处是零维护——不用管服务器、不用管备份、不用管网络，打开就用，手机电脑自动同步，服务商还帮你扛着安全补丁和可用性。

另一类是自建模式：你在自己的设备上(通常是家里的一台小服务器或 NAS)部署一套密码管理服务，保险库数据落在你自己的硬盘里，客户端连的是你自己搭的地址。它换来的是数据完全归你：你清楚数据躺在哪个柜子里，你决定备份策略，你决定它什么时候停机、什么时候升级。

第二个分叉：密钥谁掌握

光看「数据存在哪」还不够，更要紧的问题是：密钥谁掌握。这里要引入一个关键概念——零知识加密。

所谓零知识，意思是：服务商手里只存加密后的密文，而解密所需的密钥，是从你的主密码派生出来的，只存在你自己脑子里和你自己的设备里。也就是说，哪怕服务商被拖库了，攻击者拿到的也只是一团没有密钥就永远解不开的密文；服务商自己想偷看，同样做不到。

这是密码管理器行业最精妙的设计：它把「存数据」和「能解密」彻底分开了。云服务虽然把数据放在别人的服务器上，但只要它是真正的零知识架构，别人拿着你的数据也用不了。所以「数据在云端」并不自动等于「数据不安全」——关键在于它是不是零知识，以及你敢不敢把信任完全押在这家服务商身上。

云服务的便利，与那点「归属疑虑」

公平地说，云服务对绝大多数人都是更理性的选择。它免费档就够用，跨设备同步开箱即用，安全审计、2FA、分享功能一应俱全，背后有专业团队常年盯着漏洞。你付的代价，除了一点订阅费，就是把「服务器运维」这件事外包了出去。

但它有一个无法回避的信任前提：你相信这家公司不会倒闭、不会出内鬼、不会被执法机关要求交出数据、不会因为一次漏洞泄露密文。对于普通人，这个信任是划算的；但对于一些对数据归属特别敏感的人——比如本身就在折腾家里的服务器、习惯把重要数据攥在自己手里的人——这个「把钥匙托管出去」的感觉，始终是个心结。

还有一种现实顾虑：如果服务商某天改了定价、停了免费档、甚至宣布关停，你总得把自己的保险库导出带走。而自建的好处恰恰是，数据从一开始就在你手里，不存在「被平台绑住」这回事。

自建的本质，与它的真实代价

自建，本质上就是把上面那条信任链，从「信任一家公司」换成「信任你自己」。

你在自己的服务器上部署服务端，用 Docker 容器跑起来，数据目录指向你自己的硬盘，前面套一个反向代理提供加密访问。这样一来，保险库在哪、备份在哪、谁能访问，全由你说了算。后面的章节会以 Vaultwarden 为例，从安装、配置、HTTPS、备份到安全监控，一步步带你把这套系统搭起来——它兼容官方客户端，也就是说，你手机和电脑上装的还是那个熟悉的 App，只是连接的服务器从别人家换成了你自己家。

但自建不是没有代价的，这一点必须说在前面：你得自己管服务器的可用性——它半夜挂了，第二天早上你连不上自己的密码；你得自己做备份——硬盘坏了，又没有备份，就真的找不回来了；你得自己盯安全更新——服务端有漏洞，要靠你及时升级；你还得自己解决远程访问、域名、HTTPS 证书这些网络问题。这些事不难，但它们是真实存在的日常责任。

自建之后，数据到底放在哪台机器上

自建最直接的问题是：这台「自己的服务器」具体是什么？它不用是机房里的大家伙，通常就是你家里那台常年开机的小机器——可以是一块硬盘加一台旧电脑，也可以是一台两盘位的家用 NAS。

密码管理服务本身极轻量，不吃 CPU 不吃内存，真正重要的是两件事：一要 7 天乘 24 小时开机，这样你在外面才能随时连上；二要数据放在一块可靠的硬盘上，并且有备份。也就是说，自建不是买一台贵机器，而是建立一套「家里有个永远在线、数据不丢的小柜子」的基础设施。这也是为什么这本书会反复提到家用 NAS——它正好扮演这个角色。

远程访问：出门在外怎么连回家里

你在家时，手机电脑连的是局域网，访问自己搭的服务很顺。但出门在外，用的是流量或外面的 Wi-Fi，这时怎么连回家里？这是自建必须解决的一道坎。

常见思路有几种：通过反向代理给服务配一个域名，再做加密证书；或者用内网穿透、组网工具，让你在外面也像在家里一样访问。这部分内容会在后面章节展开，这里你只要建立一个概念：自建不是搭完就完事，你还得想清楚「我在外面怎么回来」,否则这个保险库就只能在家里用，实用性大打折扣。

给自己的定心丸：备份与容灾

自建最大的心理负担，是「数据在我手里，出问题我自己扛」。缓解这个负担的办法，是把备份制度化。

密码保险库文件不大，但极其珍贵。靠谱的做法是：定期把它导出或快照到另一块硬盘、另一台设备，甚至异地存一份；备份也要加密，不能因为是备份就明文乱丢。有了可靠备份，「硬盘坏了」「手滑删了」都不再是灭顶之灾。自建的自由感，恰恰建立在这种踏实的备份习惯上——你拿回了数据归属，也拿回了对应的责任。

自建不是极客专利，是一种「自己说了算」的生活方式

读到这里，可能有人会打退堂鼓：我又不是程序员，自建是不是太难了？这本书想传递的一个重要观念是：在今天的工具条件下，自建已经不再是极客专属。

你不需要从零写代码。你要做的，是照着教程在自己的服务器上，用容器方式把现成的服务跑起来，配好反向代理和加密，再把客户端指到自己的地址。整个过程，更像是「照着说明书把一台设备接好线、打开开关」,而不是「从零造一台发动机」。真正的门槛不在于技术难度，而在于你愿不愿意花一个周末，把这套基础设施一次性搭好、之后长期维护它。

而它回报给你的，是一种踏实感：你的密码、你的数据、你的备份节奏，全部在你自己家里的设备上，不依赖任何一家公司的存亡。这种「数据归属自己」的感觉，对认真对待数字生活的人来说，是云服务给不了的。

怎么选，本章给你的结论

回到本章开篇的问题：为什么需要密码管理？现在答案完整了。你需要一个工具，帮你从人脑里接管那几十个又长又随机、还不能重复的密码；你还需要决定，这个工具的后端放在哪。

如果你读完这一章，觉得「我就是想省心」,那用一款主流的零知识云密码管理器，已经能解决你百分之九十九的问题，这完全是合理的选择，一点都不丢人。而如果你读到这里，心里那点「为什么不试试自己搭一套」的火苗被点着了——那这本书就是为你写的。接下来第 2 章，我们会进入选型：先把自建方案的几个选项摆出来对比，再决定从哪一步动手。

动手之前，你最好先确认自己有没有一块「常年开机的家当地基」。如果你已经跟着 家用 NAS 家庭服务器搭建指南 把家里的服务器跑起来了，那接下来的部署会非常顺；如果还没有，家用 NAS 选购与上手指南 能帮你判断该选什么样的机器。

整章回顾下来，逻辑链条已经完整：因为人脑记不住几十个独立强密码，所以需要密码管理工具；因为浏览器保存不是真正的管理，所以需要专门的保险库；因为云服务的信任前提让人不放心，所以我们选择把它自建起来。自建的本质，就是把这条信任链的最后一环，从「信任服务商」换成「信任自己家的设备」。

需要再次强调的是，选云服务绝不是错。如果你读完只想省心，那一个主流的零知识云密码管理器，已经能把你从密码疲劳里解放出来，这完全足够。这本书面向的，是那些愿意用一个周末换长期「数据归自己」的人。它不要求你有编程基础，只要求你愿意照着步骤一步步来，并且在遇到问题时，懂得停下来查一查、等一等，而不是慌慌张张乱改一通。下一章，我们就来具体看有哪些可选的自建方案，以及哪一种最适合你从今天开始动手。在那之前，你只需要在心里先选定一件事：我愿意为「数据归自己」付出一个周末的维护成本吗？这个问题想清楚了，后面的路就好走了；想不清楚也没关系，下一章的选型对比会帮你把它想明白。本章内容到此结束。如果你读到这里已经被说动了，那从下一章开始，我们会一步一步把这套系统真正搭起来：先选方案，再装服务，然后配网络、做备份、上安全加固。不用急，跟着节奏走就好。我们下一章见。

延伸阅读

• 本章到此结束，下一章《选型》将对比几种自建方案，带你确定技术路线。
• 数据落在自己的设备上，基础是一台可靠的家用服务器，可参考 家用 NAS 选购与上手指南。
• 远程访问与网络环境准备，可参考 软路由实战手册。