我自建托管什么
自建托管爱好者描述了廉价迷你电脑、容器，以及 Tailscale、Caddy、Home Assistant、Jellyfin 和 *arr 媒体技术栈等工具，如今如何让在家替代许多消费级云服务变得切实可行。他们争论 Docker/Compose、systemd、Kubernetes 和 NixOS 之间的取舍；SQLite 与 Postgres 的优劣；以及公开暴露与仅通过 VPN 访问之间的选择，并反复提到维护负担、备份，以及如果主管理员消失时的“bus factor”问题。几位评论者指出，AI 助手大幅降低了部署与自动化的复杂度，但许多人仍认为，自建托管更像是一种发烧友爱好，而不是商业平台的主流替代方案，也不是像 AI 那样具有变革性的技术。
关于自建托管的总体看法
- 许多人觉得自建托管比以往任何时候都更容易，也更强大，但仍会把它视为一种小众/爱好，类似家庭酿酒或木工。
- 强烈的吸引力在于：控制权、隐私、避免订阅、以及比某些云服务更好的性能。
- 怀疑者强调时间成本、复杂性，以及 bus factor（“家庭实验室管理员”不在时，或者去世后会发生什么）。
自建托管 vs AI “未来”
- 一些人认为当前的 AI 经济存在泡沫，但这项技术会长期存在，并且从长远看会比自建托管重要得多。
- 也有人认为，与拥有自己的技术栈所带来的非常切实的收益相比，AI 被过度炒作了。
部署：容器、systemd 与编排
- 观点分歧很大，主要分为：
- 偏爱单个静态二进制文件的人（通常是 Go/Rust + SQLite），因为简单且可移植。
- 偏爱 Docker/Podman + Compose/Quadlets/k8s 的人，因为它们提供隔离、统一管理、易于升级和迁移。
- 有些人把所有东西都运行在 Proxmox/LXC、k3s、NixOS 或 Incus 中；另一些人则更喜欢带沙箱的纯 systemd 服务。
- Compose 文件既被赞为部署工具，也被视为简洁的架构文档。
*媒体与 arr 技术栈
- 许多人为 Sonarr/Radarr 等辩护，认为它们轻量、可靠，而且一旦配置好后基本上可以“设置好就不用管”。
- 另一些人则认为这套技术栈过度设计、脆弱，而且架构混乱；有几个人已经构建或正在构建统一的一体化替代方案，但又犹豫是否公开发布（出于法律/维护方面的考虑）。
- 对 Jellyfin 的评价褒贬不一：服务器端很棒，但对一些人来说，客户端的编解码器/HDR/字幕问题以及帧节奏问题很麻烦；另一些人则通过基于 mpv 的客户端或替代播放器来绕过这些问题。
数据库与应用设计
- 对自建托管应用而言，SQLite 受到强烈偏好：无需外部服务，备份非常简单，运维开销更低。
- 反方观点是：Postgres 也很好，而且如果你已经有一个带备份和工具的共享实例，通常会更容易；问题在于每个应用都自带自己的 Postgres 容器。
电子邮件、网络与访问
- 完整自建电子邮件被形容为很麻烦，主要原因是 IP 信誉和投递能力，而不是软件配置。中继和桥接（例如到 Proton）是常见折中方案。
- 许多人避免直接暴露服务，而是使用 WireGuard/Tailscale、Cloudflare tunnels 或类似方案；另一些人则乐于运行带 Let’s Encrypt DNS challenge 的公开 HTTPS。
- 对非技术型家人和外部分享（例如照片）的便利性，仍然是一个棘手的开放问题。
安全性、可靠性与备份
- 人们担心将复杂技术栈（*arr、媒体服务器）暴露到互联网，尤其是在 LLM 降低了攻击者门槛的时代。
- 备份通常使用 restic、ZFS snapshots 以及异地或云存储等工具；有些人会把“宠物”服务与更易丢弃的“牲畜”实例分开。