个人数据中心（第一阶段）
“个人数据中心”这个说法，其实多少有点夸张。但如果换个角度看，它确实又在往这个方向靠：文件、服务、内容、自动化，都集中在自己手里，彼此之间开始产生连接。
现在这套东西，大致是 1 个主域名、13 个子域名、24 个 Docker 容器，跑在几台服务器上。规模不算大，但已经足够把日常的数据和服务承接下来。
这篇算是第一阶段的记录，不做太多抽象，也不刻意总结，就是把当前的状态讲清楚。
从“有个博客”开始
最早其实只是想有个地方写点东西。
网站用的是 WordPress，一开始也就是发文章。但慢慢地，会觉得“文章”这种形式有点单一，于是又加了“动态”、视频、文档这些东西。
现在回头看，它已经不像一个传统意义上的博客，更像是一个对外的内容出口。有点接近社交媒体，但没有推荐算法，也没有流量分发，只有自己在上面写什么、放什么。
这件事本身没什么技术含量，但它决定了后面很多东西：既然内容在自己手里，那围绕内容的其他部分，也自然会往“自己掌控”靠。
服务越来越多之后
当服务数量开始变多，一个很现实的问题就出现了：记不住入口。
一开始是靠浏览器书签，后来发现完全不够用，于是加了一个聚合页面，用的是 Homepage。
它的作用很简单——把所有服务放在一个地方，可以看状态，可以点进去。没什么复杂逻辑，但非常实用。
中间也试过 Homarr，交互确实更好，而且不需要写配置文件。但它的集成生态还不够，很多服务接不上。现在暂时还是用 Homepage，后面再看有没有迁移的必要。
媒体这件事，反而最稳定
媒体服务选的是 Jellyfin。
这个选择过程其实很快：不开源、不支持自托管的，直接排除。剩下的里面，Jellyfin 基本是最均衡的一个。
UI、性能、客户端支持，都在一个“够用且稳定”的区间。部署之后，就没再动过。下面左右分别是 Android 音乐客户端、Android 电影客户端。
有意思的是，这一块反而是最“省心”的。其他系统都在不断调整，但媒体服务一直没变，像个基石一样放在那里。
知识库，来回折腾过一圈
知识管理这块，走过一段弯路。
最开始用的是 Notion，后来觉得数据不在自己手里，就开始找替代方案。用过一段时间本地应用，用 WebDAV 同步，也在 Obsidian 上停过一阵。
这些方案都有一个共同点：数据在本地，结构靠文件组织。但用久了，会发现另一个问题——当内容变多之后，文件系统的表达能力是有限的。链接、结构、协作，都开始变得别扭。
最后还是回到了“服务端”的思路，用了 Outline。
它的门槛其实不低，必须接身份认证，这一步就会劝退不少人。但它的界面、编辑体验，以及“写完就是页面”的这种感觉，很难替代。
现在这块基本稳定下来，用来放一些结构化的内容，比单纯写文档要清晰很多。
个人云，是最核心的一层
如果说整个系统有一个“中心”，那大概就是个人云。
这部分我换过最多次：从 ownCloud，到 Nextcloud，再到 Pydio Cells，最后到现在的 OpenCloud。
从 PHP 到 Go，这个转变其实挺明显的。一方面是性能和资源占用，另一方面也是对运行环境的控制。
Pydio Cells 用了一段时间，但它对存储抽象为 S3，这一点我不太认同。对我来说，本地存储就应该是“本地”，不需要再套一层概念。
OpenCloud 目前还在早期，但已经能承担主要职责了：同步、访问、权限，都在一个可接受的范围内。
不过这一块，我没有把它当成“最终方案”。还有几个项目在看，包括 Go 版本的 ownCloud，后面有可能会调整。
自动化开始出现之后
当服务逐渐稳定下来，会自然产生一个需求：让它们动起来。这时候就用上了 N8N。
一开始只是做一些简单的事情，比如自动整理内容、做一些推送。后来慢慢发现，它更像一个“连接层”，可以把原本孤立的服务串在一起。
和写脚本不太一样，工作流是可视化的，也更容易复用。很多事情，一旦做成流程，就可以长期运行，不用再去手动处理。
这部分还在慢慢扩展，目前只是刚刚起步。
身份系统，算是一个分水岭
在引入 SSO 之前，这些服务其实是彼此独立的。每个系统一套账号，登录状态也各自分散。用起来不算麻烦，但明显是割裂的。
一开始用的是 Zitadel，但用下来感觉它更偏向“企业级”，权限模型很复杂，很多设计是为多组织、多角色准备的。
后来换成了 Authentik，整体简单直接一些，也更容易和现有系统融合。
从那之后，整个系统开始有了一个“统一入口”的感觉。虽然只是一个认证层，但它把所有服务连在了一起。
下载这块，还不太满意
目前用的是 qBittorrent 加 Filebrowser。
功能上没问题，速度也很好，但总觉得这是一个“拼起来的方案”。几个明显的问题：少了 ED2K；UI、下载引擎的设置分散在不同地方。
理想状态其实很清晰：一个统一的下载系统，支持多协议，有自己的账户体系，可以接入现有的认证。
甚至再往前一步，能把“搜索下载”也整合进去。现在已经有项目在往这个方向做，但都还比较早期，还没到可以替换的程度。
备份
备份分为本地和远程两部分，都实现了自动化。
本地备份用的是 Restic（带 WebUI）。它的快照机制和增量处理都非常可靠，但 UI 相对死板，连时间格式这种基础选项都无法调整。即便如此，它稳定的核心功能仍然是主要依靠它的理由。
远程备份用的是 Duplicati。在评估了多种方案之后，选择它主要是出于交互体验和稳定性兼顾的考虑。
有时候也会考虑把本地任务移到 Duplicati，但目前保留 Restic 更多是为了验证其长期稳定性——可以把它当作系统的一道“稳定性检查”。
其他功能
还有一些看起来很有潜力的项目，我都关注过。
比如 Immich，它的图片管理体验非常好，性能也很出色，还有 AI 辅助组织和搜索功能，让我一度想把照片管理从个人云中分离出来交给它处理。不过仔细评估之后还是没用，有两个主要原因：一是 AI 功能对本地算力要求高，我的服务器没有 GPU，这会带来不小的瞬时负荷；二是它的组织方式不再依赖文件夹，而是通过分析元数据和识别图像内容（甚至 OCR）来分类照片，这种侵入性太强了，我不想完全交出物理层的控制权。
Photoprism 虽然允许用户更直接地掌控内容组织，但缺乏客户端支持，对于日常使用来说不够方便。综合算力、管理方式和客户端体验，最终还是由个人云负责照片管理。
另外，还有 SearxNG，把搜索请求搬到自己的服务器，并去掉追踪元数据，相当于让搜索更私密；Portainer、Beszel 等工具也都很不错，但目前都不是刚需，所以暂时还没引入系统。
到目前为止
这套系统，说复杂也复杂，说简单也简单。
复杂在于它是拼出来的，每一部分都有自己的历史；简单在于它的目标一直没变——把数据和服务尽量收回到自己手里。
现在这个阶段，算是一个“能用、稳定，但还不完整”的状态：有统一入口；有基本的身份体系；有核心的数据承载；有初步的自动化。
但还有不少地方没做完，也有一些已经在考虑替换。它更像一个正在生长的系统，而不是一个设计好的成品。
如果非要总结一句，大概就是：开始有了自己的“边界”，但边界还在调整。