迁移与取舍
我的下一步规划，不是继续往家里堆更强的硬件，而是把每一个服务重新问一遍：它为什么要留在这里，它值不值得继续自己维护，它到底更适合本地、轻量集群，还是直接放到云端。
我怎么判断一个服务该放哪里
这张图基本就是我现在的判断方式。它比“能不能搭起来”更重要，因为真正决定 Homelab 长期形态的，不是技术上能不能做，而是长期维护到底值不值得。
这里的“贴近本地”，指的是明显依赖家庭网络、私有数据或局域网联动；“公网职责”则主要指公网入口、外部协同和持续交付这类更适合放到云端的工作。
优先上云的职责
我希望最先稳定下来的，是那些天然更适合放在公网或云端的能力：
FRPS、反向代理、外部入口、探针和镜像分发继续优先放在 VPS- 云端单节点
Kubernetes继续承接 GitOps、Argo CD和部分公共服务 GitHub Actions -> Registry -> Argo CD -> K8s这条链路继续往可重复交付方向打磨
原因也比较明确：
- 国内访问与公网接入更友好
- 公网职责和家庭局域网职责能更清楚地拆开
- 以后更换本地硬件时，不需要把所有外部能力一起搬家
必须留在本地的能力
本地环境更适合保留这些职责：
Synology这类本地存储能力RouteOS、MosDNS + Mihomo这类直接影响家庭网络体验的组件- 更贴近私有数据、局域网访问或本地联动的服务
- 必须和现有家庭网络条件深度耦合的基础能力
这样收缩之后，本地环境的重点就不再是“做一个小型数据中心”，而是保留真正离不开本地的那部分根。
轻量 k3s 的角色边界
两台 RK3566 的轻量 k3s 会继续保留，但我会更明确它的定位：
- 跑一部分低风险、可持续使用的服务，例如
OpenWebUI、Home Assistant、Traefik - 继续练
Argo CD、GitOps 和资源受限条件下的 Kubernetes - 不把所有关键路径都压到这层环境上
我希望它足够真实，但不需要它承担全部“生产级”期待。
重状态服务怎么判断
对于数据库、对象存储这类状态更重的能力，我会继续比较自建和托管方案的边界：
PostgreSQL：本地保留必要实例，但会继续评估Supabase PostgreSQLMinIO：继续作为自建S3兼容能力实验，同时评估Cloudflare R2- 不再默认把所有状态服务都做成“必须自己维护”
我更在意的判断标准是：
- 值不值得自己长期运维
- 迁移和备份成本是否可接受
- 故障恢复是否比托管方案更麻烦
我刻意不做什么
- 暂不继续追求高配本地机器扩容
- 暂不强行把所有服务都塞进 Kubernetes
- 暂不在本地继续堆更重的高可用状态集群
这些不是能力问题，而是我现在更在意“长期跑得稳”和“维护成本可控”，而不是把架构继续做大。
我希望最后形成什么形态
如果这条路线能继续稳定下来，它最后形成的不会只是一个“放服务的地方”，而会更像我长期打磨平台工程判断力的练习场：
- 本地根基：网络、存储、私有数据和强本地依赖能力
- 轻量集群：低风险服务、
k3s练习和持续的 GitOps 实验 - 云端协同：公网入口、持续交付和更适合外放的工作负载