我很早就在自托管（self-hosting）世界里，大学一年级把网站跑在床下的Linux（Linux）主机上，室友嫌风扇吵关机导致停机；后来几年用过MythTV（MythTV），之后又用XBMC（XBMC，也就是后来的Kodi（Kodi））。不久前，我在印度住了几年，流媒体很便宜，家里用网飞（Netflix）、迪士尼Plus（Disney Plus，印度名为Hotstar）和Spotify。离开印度后，我不愿付西方价格，也厌倦了推荐与自动连播对儿子的影响，于是改用自托管的Jellyfin（Jellyfin），并在接下来一年半里由此扩展自托管。
正文
我一直有一只脚踏在自建服务（self-hosting）的世界里，早在它被称为这个名字之前就是这样。大学一年级时，我在床下的 Linux 主机上运行一个网站。有一段时间服务中断，因为我室友受不了风扇噪音，把电源关了。有几年我跑 MythTV，后来是 XBMC（后来改名为 Kodi）。
最近，我在印度住了几年，那里的流媒体服务按西方标准来看极其便宜。我们用了 Netflix、Disney Plus（在印度叫 Hotstar）和 Spotify。离开印度后，我不愿意为这些服务支付西方价格。但我也受够了那种不断诱导用户继续观看的机制，尤其是考虑到我儿子。我们想把他的观看选择限制在某些节目上，但不断出现的“为你推荐”和“接下来播放”引发了冲突。虽然可以把内容限制在特定影片，或者禁用自动播放，但为每个服务都做这些设置，还要跟踪客户端应用什么时候改版、需要重新配置，实在太麻烦了。
于是，我从另一种意义上“剪断了线”（cut the cord），放弃流媒体服务，转向自建 Jellyfin。在接下来的一年半里，Jellyfin 为我打开了自建许多其他服务的大门，减少了我对云服务提供商的依赖，也带来了一种令人安心的稳定性。我不再被迫不断面对不必要的网站改版、价值可疑的新功能，以及关于服务条款更新、强制仲裁、数据泄露等堆积如山的电子邮件。我会阅读自己托管的软件新版本的发布说明，然后决定要不要升级、什么时候升级。
规则
我有几条基本原则。
除了运行在我路由器上的 VPN 服务器外，我不会把任何服务直接暴露到公共互联网上。不管这有多方便，也不管某个应用有多安全，我都不这么做。尤其是在有 AI 辅助黑客攻击的今天，我认为这根本不明智。我的 ISP 对 IPv4 地址也使用了 CGNAT，所以我的家庭网络无法通过 IPv4 从公共互联网直接访问。我的 VPN 服务器只能在 IPv6 上公开路由，这个限制有一些缺点，但对我的使用场景来说还行，而且可能有助于减少不怀好意的连接尝试。最大的缺点是，我的 VPN 几乎永远无法在公共 Wi-Fi 网络上使用，因为这些网络很少提供 IPv6。用手机时，我可以关掉 Wi-Fi，通过移动数据连接……如果有信号的话。
在可能的情况下，我更喜欢原生运行服务，但对于复杂的服务或依赖很多的服务，我会把它们容器化。我喜欢那种只是一个 Go 二进制文件的服务。如果某个服务只提供 Docker compose 文件，还想跑 MySQL、Redis 和另外三个容器？那我已经在找替代方案了。如果依赖不算太夸张，原生方式更好、更快、更高效。我可以在多个服务上使用相同的管理工具和命令。不必为了运行某条命令而进到这个容器里，然后发现这个容器里没有 curl，那个容器跑的是 busybox 所以所有参数都不一样，也不必去应付虚拟网络和主机端口映射，这些都不需要额外的心智负担。
与此相关的是，我不再用 Docker 了。这其实不算什么原则性立场，但我厌倦了不得不在服务器上管理一套完全独立的服务控制系统。我已经在用 systemd 了，而如今 Podman 与 systemd 的集成已经非常出色。
硬件
去年我买了一台 Beelink 迷你电脑，具体是 S12 Pro，配备 Intel N100 处理器、16 GB 内存和 512 GB 内置 SSD。那是在内存价格暴涨之前，所以我花了 180 欧元。亚马逊上同一个商品现在要 359 欧元。哎哟！服务器还挂了一块 6 TB 的硬盘用于媒体存储。
我在 Hacker News 上的评论 讲了自建的东西，有人问这些怎么能在 16 GB 内存上跑起来。正如我在下面描述的，我做了一些降低服务器资源需求的选择，但最终结果发现，要跑很多东西其实并不需要多强的硬件。显然我并没有在这台硬件上跑任何本地 AI 推理，但对于所有非 AI 的东西，它开箱即用，或者稍微改一下配置就能跑得很好。
服务
按字母顺序排列。
Actual Budget
预算软件，有桌面客户端和网页应用，支持自定义报表和基于规则的分类。我只用它来做预算，以及追踪支票/储蓄/信用账户。至于投资账户，我用的是云服务。总有一天我会试着从后者迁移出来……
虽然 Actual Budget 支持从多家银行自动导入交易，但我没用这个功能。相反，每个月结束后，我会下载上个月银行流水（优先 OFX 格式，没有的话用 CSV），然后手动导入。这对我来说没问题，因为我主要用 Actual Budget 来追踪支出，而不是……真正的……做预算。
Podman。
Audiobookshelf
在服务器上添加、下载和存储有声书和播客，然后在手机上收听。我没怎么用过有声书功能，主要是给孩子们搭的，但它的章节处理做得很好。以前播客我用 PlayerFM，后来是 Pocket Casts，但现在除非出门在外且没有 VPN 连接，我都用 Audiobookshelf。
原生。
Automatic Ripping Machine (ARM)
ARM 能自动翻录和转码 DVD（也支持蓝光，但我不弄蓝光）。没错，现在已经是 2026 年了，我还在翻录 DVD。别忘了，我们已经“剪断了线”，所以这不仅是获取新内容的途径，也是我们获得双语内容（英语和法语）的一种方式。
Podman。
Backrest
Restic 备份软件的网页界面。备份很重要！对 Immich（照片）来说尤其重要。Restic 在去重和压缩备份数据方面做得很好，而 Backrest 让管理存储保留策略变得容易。失败时的通知会发到 Gotify。
原生。
Beszel
Beszel 是一个简单的监控面板，从 agent（这里指老式的小型后台服务）收集基本统计数据，显示 CPU 负载、内存和磁盘使用情况、温度、电池等。它帮我留意家里其他各种主机（几台树莓派和一个 Proxmox 集群，以后可能会写一篇帖子讲这个）。
原生。
Caddy
Caddy 是一个网页服务器和反向代理。早期我不理解反向代理的价值，觉得用本地 DNS 名、甚至 IP 地址和端口号来访问服务就够了。但后来我开始加越来越多的服务，有些还要求 HTTPS。于是我买了一个域名（不是这个），并设置 Caddy 自动获取 LetsEncrypt SSL 证书，现在几乎所有服务都能在局域网（或通过 VPN）用 HTTPS 和好记的子域名访问。添加新服务只需要快速改一下 Caddyfile。
原生。
Cockpit
Cockpit 是服务器的网页管理控制台。它使用正常的系统认证方式。对我来说，它的主要用途是在某些服务没设置通知时，发现那些失败的服务。
原生。
Forgejo
Forgejo 是 Gitea 的一个分支，以单个二进制文件部署。如今 Github 的正常运行时间成了很多笑话的素材，但我也很欣赏拥有自己的 git remote 的速度。最终我会设置 CI/CD 和 runners，哪怕只是为了部署这个博客。
原生。
基于网页的 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，我用 Gotify 接收各种通知：哪些服务或设备挂了、我孩子在 Jellyfin 上看什么、Audiobookshelf 里什么时候有新播客剧集，等等。
原生。
Home Assistant
Home Assistant 大概值得单独写一篇帖子。它非常棒，我无法想象在 Google Home、Amazon Alexa 或 Apple Home 这种专有生态里能实现同样的事情。现在设备制造商正在标准化 Matter 等协议，情况有所好转，但 Home Assistant 带来的控制和灵活性还是难以匹敌。不过它的学习曲线很陡，我需要认真考虑在服务器可能出现故障时，如何切实地保证家里的基本功能不受影响。
Podman。
Homepage
某个时候我意识到，我跑了太多服务，以至于需要另一个服务来专门管理它们。Homepage 是个不错的解决方案。它几乎为我运行的所有服务都提供了小部件，所以我可以快速总览当前状态，或者只是快速跳到某个服务的子域名。
Podman。
Immich
Google Photos 的替代品。我受够了 Google 在应用里不断推销付费存储套餐。我还能管理好自己的存储空间，但我妻子总是快要把空间用完了。去年我们迁移到了 Immich，就在版本 2 发布后不久。当所有网络活动都在家里进行时，加载满是照片的页面要快得多。我也想出了和家人分享相册的办法。Immich 还有很多要做的工作——我有很多重复照片，而且现在存储不再是问题，我在清理照片和视频时就没那么克制了。
Podman。
Jellyfin
正如我在开头提到的，我自建媒体服务已经很久了，最早可以回溯到二十多年前的 MythTV。Jellyfin 对媒体组织方式有自己固执的一套，但通常工作得很好。我只用它来看电影、电视剧和家庭视频，所以没法评价它的其他功能（电子书、音乐、照片等）。虽然我儿子还记得 Netflix，但他对 Jellyfin 很满意。我很欣赏它没有自动播放、永远看不到推荐，也不用在一堆垃圾内容里翻找我想看的东西。
我管理资源需求的一个方法是，通常优先选择 720p 而不是 1080p 或更高分辨率的媒体。显然翻录 DVD 时，只能是 576p 或 480p。我确实有一台 4K 电视，但尺寸不是特别大，虽然我能看出标清和高清的分辨率差异，但对几乎所有内容来说，720p 对我来说已经足够了。
Podman。
Music Player Daemon (MPD)
有些解决方案就是能用，而且真的不需要改变。我认为 MPD 就是其中之一。它已经存在 23 年了。虽然 Gonic 很适合在手机上听音乐，甚至通过 VPN 在外时把家里的音乐串流到手机，但我用 MPD 通过 Snapcast 把音乐播放到全屋音响系统。我跑了两个 MPD 实例，一个放音乐，一个放播客。
原生。
PocketBase
以前，我把特殊账户（HSA、529 等）的交易和收据记录在一个 SQLite 文件里，直接用 SQL Workbench/J 访问。但随着我在不同国家、货币和保险系统之间迁移，事情变得更复杂，而且我也想让我妻子能录入交易。我迁移到了 PocketBase，它本质上还是一个 SQLite 文件，但带有一个好看的网页管理前端，我把它当成通用的 CRUD 前端来滥用。它足够简单，我妻子也能用，而我仍然可以对底层数据库文件运行任意查询。
原生。
Readeck
Readeck 让我能给读过的东西打标签并存档副本。读研时我是 Zotero 的重度用户，但我已经好几年不需要写参考文献了。不过，我仍然会读一些希望以后还能访问的内容。我先试了 Wallabag，但它在存档付费墙内容时有问题，哪怕我在手机上登录了也不行。相比之下，Readeck 会把我手机上看到的内容存档并存储到我的服务器上。
原生。
Samba
Samba 提供共享网络存储，可以轻松地往服务器拷文件、从服务器拷文件，或者和我妻子分享重要文档。有意思的是，一个最早在 1980 年代开发、最常与 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，而 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 播放列表的简单网页应用。我通常用 yt-dlp 下载 YouTube 视频，或者用 NewPipe 在手机上看，但 Yubal 会正确地为从 YouTube Music 下载的音乐命名、整理和打标签。
Podman。
不自建的服务
下面是一些我不自建、试过但决定放弃、或者不太可能尝试的东西。
The *arr Stack
Sonarr, Lidarr, Radarr 等等。每次我读到搭建它的教程，听起来都像是一个资源密集型的烂摊子，本质上还容易频繁出问题。这和我选择自建服务时想要的完全相反。
Collabora Online
虽然能和 Google 彻底分道扬镳是件好事，但 Google Docs 作为一种极其方便、易于访问的信息存储和共享方式，很难被击败。不过，除非有特定原因需要把文档放在云端，我还是会选择 LibreOffice Writer 和 Calc。既然我已经有了共享网络驱动器，那么跑一个像 Collabora Online（网页版办公套件）这样的服务，而不是直接在本地用 LibreOffice，似乎毫无意义。
Firefly III
在用 Actual Budget 之前，我试过 Firefly III，当时觉得我需要内置的多币种支持。它的搭建很复杂，涉及多个容器，还包括一个专门用来导入数据的容器。Actual Budget 的搭建和使用要简单得多。对于我的外币账户，我自己写了个简单的脚本处理汇率换算，所以 Actual Budget 里所有东西都以美元计价。
Owntracks
我喜欢 Google Maps Timeline，但在 Google 把位置数据限制在单个设备之后，我希望能找到一个自建版本。但无论我尝试多少电池或位置设置，都无法让 OwnTracks 的 Android 应用持续上报我的位置。Dawarich 是这个领域的另一个选择，但它想要“至少”跑四个容器（PostgreSQL、Redis、Sidekiq 和网页应用）。对我来说，用这些资源换取我可能获得的价值并不划算。
Music Assistant
如果你还没有自己喜欢的音乐方案，Music Assistant 可能更适合你。至于我，我已经有 Gonic、Snapcast 和 MPD 跑得很好了。Music Assistant 给我的感觉是它想“拥有”一切；例如，它似乎在不断重新排列我的 Snapcast 设备组。
电子邮件
自建电子邮件似乎是投入巨大而收益甚微。我不能冒无法收发电子邮件的风险。最终我希望从 Gmail 过渡到一家付费提供商。
结论
总共有 17 个原生服务和 11 个 Podman 服务，全部由 systemd 管理。htop 显示当前大约用了 7.5 GB 内存，CPU 在 30% 到 40% 之间波动。事实证明这台迷你电脑能跑很多东西！鉴于 AI 热潮导致电脑硬件变得如此昂贵，我希望能继续看到那些优先考虑简洁和高效的自建项目。
评论
讨论气氛以经验分享和互相支招为主，多数自建者对自建整体持肯定态度，但在具体实践上分歧明显：文章对 Sonarr、Radarr、Lidarr 等 *arr 栈以及 Jellyfin 的负面印象遭到不少人的反驳，认为它们其实轻量稳定；与此同时，远程访问方案、声明式容器化与极简原生的取舍，以及个别服务和硬件的体验坑，成为主要争论点。
认为自建栈其实轻量稳定，并非文章所称的“脆弱烂摊子”
- 多位自建者用实际资源占用和长期运行经验反驳“*arr 栈资源密集、频繁崩溃”的说法：Sonarr、Radarr 空闲内存仅一百多 MB，Jellyfin 也不算重，配合一份 compose 文件就能理清 *arr、Transmission 和 Jellyfin 的协作关系；另有评论称自建分析平台十余年没出大问题，服务只在人为改动时才容易故障，关键是做好磁盘告警等基础设置。（较多人） > *arr 工具空闲时内存占用仅一百多 MB、几乎不耗 CPU，并不笨重也不脆弱；一份 compose 文件就能讲清它们如何协同。（@eleventen）
认为远程访问与安全暴露才是自建真正的难点
- 不少人有共识：自建服务本身不难，难的是在公网空间里安全、方便地访问私有网络里的服务。Tailscale 被频繁提及，但有人嫌它在手机上要装客户端且本质是 VPN，转而用 Pangolin 在不暴露服务器的情况下自带认证地公开服务；也有人给国际亲友各放一台树莓派组成 VPN，放在访客网络里兼顾本地电视与内网隔离。（较多人） > 自建本身很棒，难点在访问；Pangolin 是不暴露服务器也能轻松公开服务并自带认证的缺失拼图。（@turtlebits）
倾向用 Docker Compose / k8s 等声明式方式统一管理
- 在多种硬件、系统和供应商上自建的人希望尽量少折腾，认为如果不用 Docker Compose 或 k3s/k8s 这类声明式、标准化部署，管理一堆服务会非常混乱；裸机直接跑原生服务尤其让人难以接受，Proxmox 等虚拟化或隔离手段几乎是刚需。（较多人） > 不用 Docker Compose 或 k8s 这类声明式方式部署这么多服务，对我来说有点不可思议。（@turtlebits）
偏好极简单一二进制、原生或 SSH/cgit，抗拒重容器栈
- 少数人明确偏爱能原生运行的单 Go 二进制，反感为一个应用拉起 MySQL、Redis 等多个容器；也有人认为个人 Git 服务只需要 SSH 加 cgit，不必上 Forgejo/Gitea，甚至用 Tailscale + Samba 就能零维护覆盖很多场景。（少数人） > 我偏爱能原生跑起来的单 Go 二进制；遇到只提供 Docker Compose 还要拉起 MySQL、Redis 和另外几个容器的服务，就会去找替代方案。（@Lucasoato）
认为自建并非全都省心：Jellyfin 播放与整体维护都有硬伤
- 少数人指出 Jellyfin 客户端在 HDR、H265、字幕和帧率 pacing 上支持不佳，高刷屏仍会卡顿，因此宁可放弃自建媒体服务器，回到 Samba 共享加本地播放器；同时也有人感叹维护整套服务像一份兼职，质疑其时间成本。（少数人） > Jellyfin 连媒体播放这个核心功能都做不好，HDR 和 H265 支持不全，高刷屏仍有卡顿。（@flaunf221）
认为面向自建者的应用应回归 SQLite，别让每个服务都自带数据库容器
- 少数人原本不认同“只要 SQLite 就够”的说法，但实际看到 Immich 之类应用各自要求独立的 Postgres 和 Redis 容器后，转而认为：如果目标用户是自建者，应用真的只需要 SQLite，不该每个都塞一套外部数据库容器；不过也有人表示能接受应用使用 Postgres 或容器数据库，并不强求 SQLite。（少数人） > 如果应用是给自建者用的，SQLite 真的就够了，不该每个都塞一个 Postgres 或 Redis 容器。（@mikeocool）
认为 AI 只是泡沫，自建托管才是真正的颠覆性未来
- 少数人把讨论上升到趋势判断，认为人们把 AI 当未来是自我纠结，AI 更像待破裂的泡沫；真正有颠覆性的是自建：家用服务器硬件已足够廉价，软件配置也逐年变简单，剩下的真正难题是公网访问。（少数人） > AI 更像等待破裂的泡沫，自建托管才是真正具有颠覆性的未来。（@austin-cheney）
有价值的补充
- 邮件方案：完整自建邮件服务繁琐且没必要，可用 mbsync 把 Gmail、iCloud、Proton 等邮箱同步到本地，再用 Roundcube 之类前端收发；还可配合 ntfy.sh 监听邮件目录发新邮件通知。（@ebrahimh）
- 音乐服务：多客户端场景下可用 Lyrion 替代 MPD，用单一 UI 管理本地网络里的所有“扬声器”。（@disposition2）
- 密码库同步：既然已经在用 Syncthing，直接用它同步 KeePass 即可，稳定用了多年，不必另找方案。（@seplox）
- 视频播放：有人自荐一个单 HTML 文件的网页视频播放器，丢进网站目录就能为视频提供缩略图、搜索、字幕等支持，无强制第三方依赖。（@pseudosavant）
- 代码托管：个人场景只需一台有 SSH 的服务器，真要 Web 界面用 cgit 就够，不必上 Forgejo/Gitea。（@GalaxyNova）
- 硬件避坑：Beelink N100 迷你主机可能过热重启，BIOS 设置在断电后丢失且售后无用，更建议买 HP、Dell、Lenovo、Asus 的二手商用迷你主机。（@ww520）
- 家庭组网：给国际亲友各配一台树莓派组成 VPN，放在访客网络里，既能看本地电视又不暴露家庭内网。（@uzairhaq）