不知不觉间，距离我第一次接触 Linux Server 已经过去了六年，而开始折腾自己的 HomeLab 也已经快两年了。这些年踩过不少坑，也积累了一些经验，因此想借这篇文章，把这段折腾历程记录下来，顺便和同样对自托管感兴趣的朋友分享一下。

硬件与系统

硬件方面，我选择了一台 Mac mini M1。作为苹果第一代 Apple Silicon 设备，它拥有约 5W 的待机功耗和不错的 CPU 性能，对于个人 HomeLab 来说已经完全够用。

我使用的是 8GB + 512GB 的版本。最初购买它只是为了看网课和写文档。依稀记得当年正值矿潮，原本计划组装一台台式机，结果预算被显卡价格劝退，只好先买了这台 Mac mini 过渡。大约使用了两年后，我还是换成了组装台式机，而这台 Mac mini 也因此闲置了一段时间。后来想到可以拿它来部署一些自托管服务，也算是让它焕发了第二春。

当然，如果你手头已经有闲置的低功耗设备或者 VPS，也完全可以直接利用起来。就目前而言，我认为并没有专门为了 HomeLab 再去购买一台 M1 Mac mini 的必要，没有必要为了折腾而创造新的消费需求。

截至目前，这台机器已经稳定运行了一年左右。硬盘占用约 100GB，在同时运行约 20 个 Podman 容器的情况下，内存占用大约维持在 3.4GB 左右，整体资源利用率让我相当满意。

系统方面，这台机器最初搭载的是 macOS Big Sur，后来一路升级到了 macOS 15。最开始运行服务时，我依旧选择了原生 macOS，但用久之后便逐渐暴露出不少问题。

首先，macOS 的许多设置仍然依赖 GUI 完成，在纯 SSH 环境下操作并不方便，很多时候不得不额外开启 VNC。其次，桌面环境本身也会占用不少系统资源，再加上 OrbStack 运行多个容器后，内存压力会明显增大，频繁使用 Swap 对 SSD 也并不友好。此外，使用 macOS 作为服务器本身就是一个相对小众的需求，相关文档和社区资源远不如 Linux 丰富，遇到问题时往往很难找到成熟的解决方案。

后来，我在刷 B 站时偶然了解到 Asahi Linux 项目。这个项目致力于让 Apple Silicon Mac 原生运行 Linux。目前，它已经能够较好地支持大部分 M1 和 M2 设备。就我这台 Mac mini M1 而言，基本没有遇到什么严重问题，作为服务器使用已经完全足够。

安装过程直接参考官方文档即可，整个流程基本都是引导式操作，没有太高门槛。分区时建议给 Linux 多预留一些空间，毕竟大概率之后就不会再频繁进入 macOS 了。我个人只给 macOS 保留了约 100GB 的空间。

发行版方面，Asahi 官方主要支持 Fedora Linux，这也是我目前正在使用的系统。整体使用下来稳定性相当不错，我甚至曾经直接从 Fedora 42 升级到 Fedora 44，也没有出现任何问题。除此之外，Ubuntu、Debian、Arch Linux ARM、Void Linux 以及 Gentoo 等发行版也都有社区贡献者提供支持，这里就不再展开讨论了。

我部署的服务与部署方式

我目前在这台 HomeLab 上部署了如下服务：

我所选用的服务大多都是开源软件。像 CloudDrive2 这种暂时缺乏成熟 FLOSS 替代方案的软件，我则使用了它的免费版本。这里重点聊聊，我为什么会在众多同类项目中选择它们。

相比 PhotoPrism，Immich 提供了官方的 iOS 和 Android 客户端，手机照片同步体验方便了许多。启用之后，再也不用担心 iCloud 免费版那可怜的 5GB 空间天天弹出容量不足的提醒了。而且，你的照片也不用担心遭到某些网盘平台的和谐。

我主要使用 Jellyfin 来托管自己的动漫和音乐库，并将资源直接存储在本地，而不是依赖云盘。

原因主要有两点：首先，Jellyfin 对 CloudDrive2 挂载目录的扫描速度较慢；其次，虽然通过 strm 文件等方式可以显著提升扫库效率，但往往需要额外部署重定向服务，并对 Jellyfin Web Client 进行一些修改。对于我来说，这套方案还是过于折腾了。

况且，我真正会反复观看和收听的资源其实并不多，因此直接本地存储反而成了一个更简单、也更稳定的选择。

此外，相比 Emby、Plex 等需要付费才能解锁完整客户端体验的方案，Jellyfin 在客户端生态和功能开放程度上都更加自由，也不需要费心去寻找各种来源不明的破解版。

FreshRSS 则主要用于同步我的 RSS 订阅和阅读进度，实现手机、台式机以及笔记本之间的无缝衔接。配合 RSSHub，主流网络平台上的大量信息都可以重新以 RSS 这种“旧时代”的方式获取，从而尽可能摆脱算法推荐带来的信息茧房。

部署方式上，除了 Tailscale 和 CloudDrive2 是直接安装在宿主机上的，其余服务我都通过 Podman Rootless 配合 systemd Quadlet 进行管理。所有数据统一存储在 ~/containers 目录中，方便后续备份与迁移。

平时登录服务器时，我主要使用 OpenSSH 客户端；如果遇到网络故障，也可以直接切换显示器输入源，接上键盘后在 TTY 环境下进行维护。

至于远程访问，我选择将一个泛域名通过 CNAME 解析到 Tailnet 提供的 ts.net 域名，再配合 Caddy 作为反向代理。这样既避免了服务直接暴露在公网环境中，也保证了所有安装了 Tailscale 的设备都能通过统一的域名安全访问这些服务。

相比 Cloudflare Tunnel 的方案，Tailscale 可以自动选择最优链路，并尽可能建立 P2P 直连。在大多数情况下，我都能够直接通过 IPv6 GUA 使用移动网络访问家中的服务器。此外，我还部署了私有 Derper 服务器，用来保证在 Hard NAT 环境下的连接质量。

这里放一张简单的域名解析示意图：

*.example.com
      │
 CNAME
      │
xxxxx.ts.net
      │
 Tailscale Tailnet
      │
 Caddy Reverse Proxy
      │
 HomeLab Services

至于具体每个服务的部署过程，本文就不再详细展开了。实际上，在熟悉 Quadlet 的工作方式之后，大部分容器配置都大同小异，无非是修改几个 Volume 和 Environment 参数而已。后续如果有机会，我可能会单独写几篇文章来记录其中的一些经验。

聊聊自托管

使用这些自托管服务已经有一段时间了。在我看来，自托管最大的价值主要体现在自由和成本两个方面。

首先，通过上文提到的这些项目，我们可以轻松搭建属于自己的数字资源中心，而不必忍受各种广告、DRM 限制以及越来越高的订阅费用。无论是影音资源、照片管理还是 RSS 阅读，都能够以更加聚合和自主的方式完成。

其次，你不用担心某个平台突然倒闭、封禁账号，或者悄悄收集和上传你的个人数据；也不会因为过度依赖某家公司的生态而难以迁移。某种意义上，自托管也是重新夺回数字时代数据主权的一种尝试。

当然，自托管并非只有优点。

与云服务相比，自托管意味着你需要承担更多维护工作：系统更新、数据备份、故障排查以及安全加固，都需要亲力亲为。很多时候，一个看似简单的问题，可能就会消耗掉整个周末。

例如，我曾尝试在 Fedora Asahi Remix 上使用 Box64 替代 QEMU，以便在 Podman 中运行某个仅提供 x86_64 版本的闭源容器。折腾了许久，查阅了大量资料，最终还是没能找到可行方案，只能选择放弃。

此外，我认为，在开始部署某个服务之前，更应该先思考它是否真正解决了自己的某个实际问题，例如数据同步、媒体管理或者订阅成本。

不少人会不断尝试新的服务，却很少真正使用它们，最终陷入“为了折腾而折腾”的循环。折腾本身固然有趣，但我们也需要时不时停下来问问自己：这个服务，是否真的改善了自己的数字生活？

希望每个人都能在折腾 HomeLab 的过程中，收获乐趣，也收获便利。