我自托管了什么
内容
哪些东西我会自托管，哪些不会，以及为什么
我一直以来都与自托管结缘颇深，尽管那时还没有这个说法。大学一年级时，我就用床底下的一台 Linux 主机运行网站。室友听烦了风扇噪声，索性把机器关掉，网站也因此停机过一阵子。我连续几年运行 MythTV，后来又换成 XBMC（后来更名为 Kodi）。
前几年，我在印度住了几年。那里的流媒体服务按西方标准来看极其便宜。我们家里有 Netflix、Disney Plus（印度版名为 Hotstar）和 Spotify。离开印度后，我不愿意再按西方的价格支付这些服务的费用。但我也已经受够了那套以用户参与度为导向、不断推着人继续看的机制，尤其是它对我儿子的影响。我们希望限制他能观看的节目，但没完没了的“为你推荐”和“接下来播放”总让我们发生冲突。虽然可以把内容限定为指定片名，也可以关闭自动播放，但要为每项服务逐一设置，还得追踪客户端应用何时更新并需要重新配置，实在太费事。
于是，我从另一个意义上“剪断了线”：放弃流媒体服务，转而使用自托管的 Jellyfin。在接下来一年半里，Jellyfin 让我开始自托管许多其他服务，减少了我对云服务商的依赖，也带来了令人安心的稳定性。我不再需要不断面对毫无必要的网站改版、价值可疑的新功能，以及有关服务条款更新、约束性仲裁、数据泄露等内容的邮件轰炸。如今，我会先阅读自己所托管软件新版本的发布说明，再自行决定是否升级以及何时升级。
基本原则
我有几条基本原则。
除了运行在路由器上的 VPN 服务器外，我不会把任何服务直接暴露在公网。无论这样会多么方便、应用本身又多么安全，我都不在乎。尤其在黑客攻击已经可以借助 AI 辅助的今天，我只觉得这么做不明智。我的 ISP 也使用 CGNAT 处理 IPv4 地址，因此我的家庭网络无法通过 IPv4 从公网直接访问。我的 VPN 服务器只有 IPv6 地址在公网中可路由。这项限制虽然有一些缺点，但足以满足我的使用场景，而且很可能有助于减少恶意连接尝试。最大的缺点是，我的 VPN 在公共 Wi-Fi 网络上几乎无法使用，因为这类网络很少提供 IPv6。使用手机时，我可以关闭 Wi-Fi，改用移动数据……前提是当地有移动网络覆盖。
如果可以，我更愿意让服务以原生方式运行；但对于本身复杂或依赖较多的服务，我会使用容器化。我的偏爱很简单：一个服务最好只是一个 Go 二进制文件。可如果某项服务只提供一个 Docker Compose 文件，还要求运行 MySQL、Redis 和另外三个容器？我已经在找替代方案了。只要依赖没有多到令人望而生畏，原生运行就是更好、更快、更高效的选择。我还可以在多个服务上使用相同的管理工具和命令。这样就不必为了执行某条命令而进入某个容器，不会发现这个容器没有安装 curl、那个容器运行的是 busybox，所以所有参数都不一样，也不用处理虚拟网络和主机端口映射。
与此相关，我不再使用 Docker。这谈不上什么原则性立场，只是我厌倦了在服务器上额外管理一套完全独立的服务控制系统。服务器本来就在使用 systemd，而现阶段 Podman 与 systemd 的集成已经非常出色。
硬件
去年我买了一台 Beelink 迷你 PC，具体型号是 S12 Pro，配备 Intel N100 处理器、16 GB 内存和 512 GB 内置 SSD。购买时，那波“内存末日”（rampocalypse）尚未到来，所以我只花了 180 欧元。Amazon 上同一条商品目前标价 359 欧元。哎哟！服务器还连接着一块 6 TB 硬盘，用于存储媒体。
我在 Hacker News 上关于自托管内容的评论引出了不少疑问，大家很好奇这一整套东西如何在只有 16 GB 内存的情况下运行起来。正如下文所述，我采取了一些能够降低服务器资源占用的做法，但最终事实证明，运行很多东西并不需要多少硬件。显然，我不会用这套硬件进行任何本地 AI 推理，但所有非 AI 用途要么开箱即用，要么只需稍作配置调整。
服务
按字母顺序排列。
Actual Budget
一款预算管理软件，提供桌面客户端和 Web 应用，并支持自定义报表及基于规则的分类。我只用它做预算，以及管理支票、储蓄和信用账户。投资账户则使用云服务跟踪。总有一天我会试着摆脱后者……
虽然 Actual Budget 支持从多家银行自动导入交易记录，但我没有使用这项功能。每月结束后，我会下载上个月的交易记录（优先选择 OFX 格式，没有其他选择时才使用 CSV），再手动导入。这样适合我，因为我主要把 Actual Budget 当作支出追踪工具，而不是用它来做……真正的预算管理。
Podman 部署。
Audiobookshelf
在服务器上添加、下载和存储有声书与播客，并在手机上收听。我没怎么用过有声书功能，搭这套服务主要是为了孩子们，但它的章节处理非常出色。过去我收听播客用过 PlayerFM，后来又换成 Pocket Casts；不过现在，除非人在外面且无法连接 VPN，我都会使用 Audiobookshelf。
原生部署。
Automatic Ripping Machine (ARM)
ARM可自动完成 DVD 的抓取（ripping）和转码（也能处理蓝光，但我不弄蓝光）。没错，现在都 2026 年了，我还在抓取 DVD。记住，我们可是“剪断了线”的，所以它不仅是我们获取新内容的渠道，也能让我们获得英语和法语双语内容。
Podman 部署。
Backrest
Restic 备份软件的 Web 界面。备份很重要！Immich（照片）尤其如此。Restic 能很好地对待备份数据进行去重和压缩，而 Backrest 让存储保留策略的管理变得轻松。发生故障时，通知会发送到 Gotify。
原生部署。
Beszel
Beszel 是一个简洁的监控面板，它从各个代理（agent；此处采用传统含义，即小型后台服务）收集基础统计数据，用来显示 CPU 负载、内存和磁盘使用率、温度、电池状态等。它有助于我留意家中各处其他主机的运行情况，包括几台树莓派和一个 Proxmox 集群；这个集群也许值得另写一篇文章介绍。
原生部署。
Caddy
Caddy 是一款 Web 服务器和反向代理。早期我不明白反向代理的价值，觉得通过本地 DNS 名称，甚至 IP 地址加端口号访问服务就够了。但后来服务越来越多，其中一些还需要 HTTPS。于是我买了个域名（不是本文使用的这个），配置 Caddy 自动获取 LetsEncrypt SSL 证书。现在，几乎所有服务都能通过 HTTPS 和好记的子域名在局域网（LAN）或 VPN 上访问。新增服务时，只需快速编辑一下 Caddyfile。
原生部署。
Cockpit
Cockpit 是一个基于 Web 的服务器管理控制台。它使用常规的系统身份验证方式。对我而言，它主要有助于发现那些没有设置通知、出现故障后不会主动告警的服务。
原生部署。
Forgejo
Forgejo 是 Gitea 的一个分叉项目，以单个二进制文件的形式部署。如今，GitHub 宕机已经成了众多笑柄，但拥有自己的 Git 远程仓库所带来的速度也让我很满意。Eventually，我会搭建 CI/CD 和运行器，哪怕只是为了部署这个博客。
原生部署。
FreshRSS
基于 Web 的 RSS 阅读器。如今我基本只访问两个网站，所以不怎么使用它了。不过，我确实订阅了部分自托管服务的 GitHub 发布页，以便查看新版本的功能和错误修复。
原生部署。
Frigate
网络视频录像机（NVR）。我最初使用的是 Zoneminder，因为我已经是“上年纪”的那一代用户。但很快就看出，Zoneminder 已不如当年。Frigate 一直表现极佳。我用 8 个 IP 摄像头运行它。它能在有人或车辆驶入车道时发出警报，还能与 Home Assistant 集成，驱动各种自动化操作（例如，后院检测到有人时，打开摄像头的泛光灯）。也许以后可以写一篇文章，聊聊我的 IP 摄像头折腾经历。
我把所有摄像头都设在低于其支持上限的分辨率，主要是为了避免 Wi-Fi 网络拥塞。大多数摄像头还支持分辨率更低的 RTSP 子码流，Frigate 会使用它进行运动检测和目标检测。将摄像头分辨率维持在较低水平，可以避免视频处理占用过多 CPU 和内存，也能避免录像占用过多磁盘空间。这个画质足以辨认人脸；而我国的隐私法律禁止拍摄公共通行道路，因此我的摄像头不会对准远处。
Podman 部署。
Gonic
一款用 Go 编写、兼容 Subsonic 的服务器。很多年前我购买过 Subsonic 的永久许可证，但原项目已经非常老旧，现代替代品反而更好。我运行了两个彼此独立的 Gonic 实例，一个用于儿童音乐，另一个用于成人音乐。
原生部署。
Gotify
一款用 Go 编写的简单通知服务。许多自托管服务可以直接支持 Gotify 通知，也可以通过自定义 HTTP POST 发送。我将它与 Uptime Kuma 结合使用，以便在任何服务或设备宕机、孩子正在 Jellyfin 上看什么、Audiobookshelf 有新播客单集可用等情况发生时收到通知。
原生部署。
Home Assistant
Home Assistant 大概值得单独写一篇文章。它非常出色，而让我在 Google Home、Amazon Alexa 或 Apple Home 之类专有生态中实现同样的事情，完全难以想象。如今，随着设备制造商开始统一采用 Matter 等协议，情况已经改善不少，但 Home Assistant 提供的控制力和灵活性仍然难以匹敌。不过，它的学习曲线也很陡，我需要认真思考，如何在不牺牲家居功能的前提下，应对服务器可能发生的故障。
Podman 部署。
Homepage
某个时候我意识到，自己运行的服务太多，以至于还需要另一个服务来专门追踪它们。Homepage 是个不错的解决方案。它几乎支持我运行的所有服务，并提供相应的小部件，因此我可以快速总览运行状况，或直接跳转到某个服务的子域名。
Podman 部署。
Immich
Google Photos 的替代品。我受够了 Google 不断在自家应用中推销付费存储套餐。我能管理好自己的存储空间，但妻子的空间总是快满了。去年，就在 2.0 版发布后不久，我们迁移到了 Immich。当所有网络流量都只在家中内部发生时，加载包含大量照片的页面会快得多。我也摸索出了与家人共享相册的方案。Immich 仍有很多工作要做——我有大量重复照片，而且如今不再担心存储空间，清理照片和视频时也就没以前那么自律了。
Podman 部署。
Jellyfin
正如开头所述，我自托管媒体已有很久，可以一直追溯到二十多年前的 MythTV。Jellyfin 对媒体组织方式有很强的“主见”，但总体效果不错。我只用它来看电影、电视剧和家庭录像，因此无法评价它的其他功能（电子书、音乐、照片等）。儿子虽然还记得 Netflix，但用 Jellyfin 也满意了。我很欣赏它没有自动播放、不会显示推荐内容，也不用跳过一堆垃圾内容才能找到想看的东西。
控制资源需求的一种方式，是我通常更偏好 720p 媒体，而不是 1080p 或更高画质。显然，抓取 DVD 时，源文件不是 576p 就是 480p。虽然我有一台 4K 电视，但尺寸不算特别大；尽管我能分辨 SD 和 HD 的清晰度差异，但几乎所有内容用 720p 对我来说已经足够好了。
Podman 部署。
Music Player Daemon (MPD)
有时候，解决方案就是稳定好用，并不需要频繁改动。我觉得 MPD 就是其中之一。它已经存在了 23 年。虽然 Gonic 很适合在手机上听音乐，甚至能在外出时通过 VPN 把家中的音乐串流到手机上，但整套住宅音频系统播放音乐时，我用的是通过 Snapcast 运行的 MPD。我运行了两个 MPD 实例，一个播放音乐，另一个播放播客。
原生部署。
PocketBase
过去，我会在一个 SQLite 文件中记录专项账户（HSA、529 等）的交易和收据，并直接使用 SQL Workbench/J 访问。但随着我在不同国家、币种和保险体系之间迁移，事情变得复杂起来；我也希望妻子能够录入交易。于是我迁移到了 PocketBase。它本质上仍然只是一个 SQLite 文件，但配有一个漂亮的基于 Web 的管理前端，我把它当作通用 CRUD 前端来用。它足够简单，妻子也能使用，而我仍然可以对底层数据库文件执行任意查询。
原生部署。
Readeck
Readeck 让我为读过的内容保存副本、添加标签并归档。研究生期间我是 Zotero 的重度用户，但已经很多年没写过参考文献了。不过，我仍会阅读一些内容，并希望确保自己以后还能访问。我先试了 Wallabag，但它很难归档付费墙内容，即便我已在手机上登录也是如此。相比之下，Readeck 会把我手机上看到的内容归档，并存到服务器上。
原生部署。
Samba
Samba 提供共享网络存储，方便我在服务器与本地设备之间复制文件，也能与妻子共享重要文档。有意思的是，一个最初开发于 20 世纪 80 年代、如今最常与 Windows 联系在一起的文件共享协议，至今仍是局域网跨平台文件共享的最佳选择。
原生部署。
slskd
原生部署。
Snapcast
Snapcast 提供全屋同步音频。可以把它理解成 Sonos，但没有昂贵的厂商锁定，也没有故意让产品很快过时的做法。这个主题同样值得单独写一篇文章。它配置起来很复杂，但运行效果非常好。最终我计划再买一些设备，主要用作 Snapcast 接收端。
原生部署。
Syncthing
Syncthing 是我 Immich 照片备份策略的一部分。我在 MacBook 上设置了单向同步（仅接收），这样 Immich 中的所有照片最终都会复制到 MacBook 的外置硬盘中。
原生部署。
Transmission Daemon
这个也不言自明。
原生部署。
Uptime Kuma
在多次听妻子说“X 用不了了”、继而手动重启某个服务后，我意识到自己需要一种方式来跟踪各项服务是否正在运行。Uptime Kuma 很简单，却有一套实用的功能。我可以对设备进行 Ping，确保其在线；查看 Podman 容器状态；检查各项服务是否返回 HTTP 2XX 响应码；甚至解析 JSON 载荷并提取部分字段，用于健康检查。如果有服务宕机，我可以发送 Gotify 通知（当然，会先重试几次）。
Podman 部署。
Vaultwarden
Bitwarden 的自托管版本。多年来我使用 KeePass，但一直找不到好的同步方案，所以干脆不在手机上登录各种服务。与此同时，妻子使用 LastPass，而它先后曝出数据泄露和其他安全事故，自动填充功能也不怎么好用。把妻子迁移到 KeePass 并不现实，于是我选择了 Vaultwarden——它是 Bitwarden 的开源、API 兼容复刻版，可配合官方 Bitwarden 客户端使用。我不太喜欢 Bitwarden 的浏览器扩展，但总体还能接受。Android 应用够用了；连接到局域网时会无缝自动同步，否则我可以通过 VPN 连接，并在需要时手动触发同步。
我有点担心 Bitwarden 最终可能会对 Vaultwarden 采取敌对行动，导致客户端兼容性被破坏。目前，据我所知，另一款主要的 Bitwarden 兼容客户端是 Keyguard，但它没有开源许可证，并采用免费增值模式。
Podman 部署。
Vikunja
大约十年前，我开始使用 Trello。但在今年早些时候 Trello 发生了灾难性的持续数日宕机后，我决定寻找一个自托管替代品。对于一项只有两名用户使用的服务，我排除了所有需要启动 PostgreSQL 或 MySQL 数据库的方案。Vikunja 默认使用 SQLite，不过也可以配置为使用其他数据库后端。它并不完美，Android 应用也缺少一些功能，但对我来说已经够用了。单二进制文件部署？当然要。
Podman 部署。
Yubal
一款用于下载 YouTube Music 播放列表的简单 Web 应用。我通常使用 yt-dlp 下载 YouTube 视频，或使用 NewPipe 在手机上观看；而 Yubal 会为从 YouTube Music 下载的音乐正确命名、整理并添加标签。
Podman 部署。
非自托管项目
下面是一些我不自托管、尝试后决定放弃，或不太可能尝试的东西。
*arr 工具栈
Sonarr、Lidarr、Radarr 等。每次读到有关搭建 *arr 工具栈的文章，都感觉它像一团资源消耗严重、而且从根本上看很容易频繁出问题的烂摊子。这与我选择自托管服务时想要的结果恰恰相反。
Collabora Online
虽然与 Google 彻底分道扬镳当然不错，但作为存储和共享信息的便捷方式，Google Docs 很难被取代。不过，除非有明确理由必须把文档放在云端，否则我仍选择 LibreOffice Writer 和 Calc。由于我已经拥有共享网络驱动器，再运行 Collabora Online（一套基于 Web 的办公套件）而不是直接在本机使用 LibreOffice，似乎毫无意义。
Firefly III
在使用 Actual Budget 之前，我试过 Firefly III，当时以为自己需要内置的多币种支持。它的配置很复杂，涉及多个容器，甚至还有一个专门用于导入数据的容器。Actual Budget 的设置和使用简单得多。对于外币账户，我自己写了一个简单脚本处理汇率换算，因此 Actual Budget 中的所有金额都保持为美元。
OwnTracks
我喜欢 Google Maps Timeline，但在 Google 将位置数据限制为只能在单台设备上查看后，我希望找到一个自托管版本。然而，无论尝试多少种电池或定位设置，我始终无法让 OwnTracks Android 应用稳定上报我的位置。Dawarich 是这一领域的另一个选择，但它要求运行“至少”四个容器（PostgreSQL、Redis、Sidekiq、Web 应用）。对我来说，相比可能获得的收益，这并不足以抵消所需的资源投入。
Music Assistant
如果你还没有一套称心如意的音乐系统，Music Assistant 可能更适合你。对我来说，我已经有 Gonic、Snapcast 和 MPD，而且运行得很好。Music Assistant 让人觉得它想“占有”一切；例如，它似乎会不断重新排列我的 Snapcast 设备分组。
电子邮件
自托管电子邮件似乎要费很大功夫，却几乎没有什么好处。我不能冒着无法收发邮件的风险。最终，我希望从 Gmail 迁移到付费服务商。
结语
总共是 17 个原生部署的服务和 11 个 Podman 服务，全部由 systemd 管理。htop 当前显示内存占用约 7.5 GB，CPU 使用率在 30% 到 40% 之间波动。事实证明，这台迷你 PC 能运行很多东西！鉴于 AI 热潮让计算机硬件变得如此昂贵，我希望未来仍能看到更多优先考虑简单性和效率的自托管项目。