#### 引子

简单来说，自托管 Docker 应用，就是把原本放在别人服务器上、需要按月付费使用的软件，搬到你自己的设备上运行。这个设备可以是家里的 NAS、一台小服务器，甚至是一台闲置的旧电脑。Docker 的作用，是把软件和它运行所需要的一切环境一起“打包”，让安装、更新和迁移都变得相对省事，不容易出错。

通过自托管 Docker，你可以运行很多日常且实用的个人服务，例如：

• 密码管理（如 Bitwarden）

• 笔记和知识管理（如 思源笔记）

• 文件同步与个人云盘（如 Seafile）

• RSS 阅读、书签管理和信息聚合（如 Readeck）

• 媒体管理与串流服务（如 Plex，Emby 等）

• 各类自动化任务、API 服务和个人工具后台

这些服务有一个共同点：数据完全掌握在你自己手里，功能和使用方式可以根据你的习惯自由调整，也不需要担心平台涨价、改策略，或者哪天突然停止服务。

这些年我多次尝试在家自托管，但几乎每次都半途而废——时间被消耗在配置、排错和文档上，而不是使用服务本身。

最近，这一状况发生了变化。日益成熟的飞牛生态，提供了完整可用的 Linux 运行环境，以及稳定、低门槛的内网穿透方案，显著降低了网络配置与运维成本。以 Claude Code、Opencode 为代表的 CLI 代理工具，可以让你在家庭服务器上进行自托管变得异常简单，而且出乎意料地“好玩”。你不再需要反复记忆或查找 Docker 语法、Compose 特性、参数含义或配置格式。因此，与其在搜索引擎中反复检索诸如“docker compose + vaultwarden + caddy + 反向代理”，再拼凑一堆年代久远、彼此冲突的博客教程，我更倾向于直接在机器上运行 Claude Code / Codex / Opencode，让它来完成这些工作。Docker Compose 本身并不复杂，但一旦涉及多台设备、端口映射、目录挂载以及不同容器之间的依赖关系，配置复杂度会迅速上升。传统路径下，你需要系统性地理解 Docker 的工作机制与最佳实践。

![](https://cdnfile.sspai.com/2026/01/19/article/79dd515162dc9007d6d848e9af3232ad.jpeg?imageView2/2/w/1120/q/90/interlace/1/ignore-error/1/format/webp)
当今流行的各种各样 CLI  Vibe Coding 软件


#### 为什么托管软件?

无止境的订阅制尤其令人厌倦。几乎每一款应用都在强调“每个月只要一到两杯奶茶或咖啡”，但叠加起来，我每个月已经不知道要请多少人喝奶茶和咖啡了。更重要的是，这些订阅并没有真正解决我的核心需求，而只是让我不断为零散、割裂的功能买单。即便愿意付费，得到的往往也是满足大众需求的功能，有些时候这些满足大部分人的需求与我个人使用习惯并不完全相符。

正是在这样的背景下，飞牛提供的稳定外网穿透成为一个关键触发点，让我终于迈出了这一步。它让我意识到，自我托管可以取代部分应用或服务。

以音乐软件为例，这是一个非常典型、也最能说明问题的场景。我已经不再使用 QQ 音乐或网易云音乐听歌了。原因很简单：我经常在境外活动，而大量歌曲仅限中国大陆地区播放，跨区后体验几乎不可用。理论上，我只能选择 Apple Music、Spotify 或 YouTube Music 这类境外主流音乐服务，先不说昂贵的订阅费用，它们在中国大陆的使用体验同样“水土不服”。而且各种歌曲的版权在不同音乐软件，你需要订阅非常多的服务，也有一些歌曲会遭到下架（变灰）。

Apple Music 最大的槽点在于：一旦更换 App Store 账号，整个曲库就会被清空一次，随后需要重新同步、重新缓存。这种与账号强绑定、不可控的机制，对长期使用者来说非常致命。Spotify 和 YouTube Music 的离线模式也同样令人沮丧——我经常在坐飞机时想听歌，却发现离线内容无法正常播放，或者需要重新联网验证。对我而言，我真正需要的是一个稳定、可预期的本地缓存机制，不受订阅策略、区域限制或反复验证逻辑的影响。

目前我的解决方案是使用 Navidrome [搭配音流](https://music.aqzscn.cn/)来听歌。音乐来源方面，则通过 [metube](https://github.com/alexta69/metube) 下载 YouTube 的音乐视频，生成 MP 3 格式，逐步维护属于自己的音乐库。实践下来我发现，这十年里我听的歌几乎没有发生太大变化，更多还是十年前、二十年前的老歌。也许是年纪使然，但这反而意味着：我并不需要最新的“无限曲库”，也不是一个无损音质的执念用户，我需要的是可控、稳定、长期可用。
类似的例子还有 [Memos](https://github.com/usememos/memos), 我非常喜欢 Flomo 这款笔记应用：它用于记录摘录和碎片化思考，支持多平台同步，设计语言克制而清晰，这一点我至今仍然非常认可。但一年一百多的订阅费用，并没有换来真正击中我痛点的新功能。最终我只使用它的低配版本，作为一个“还算顺手的捕获灵感和碎片的工具”。

在网页保存这件事上，我的需求其实非常简单：能够保存网页、支持阅读时高亮标注，并且可以在多设备之间查看和同步。Readeck 恰好满足了这些需求，而且完成得相当克制。界面干净，排版清晰，阅读体验舒适，对移动端的支持也很到位。它可以记住我上一次阅读的位置，并在再次打开时直接带我回到那里——这些细节对长期阅读来说非常重要。我曾经使用过 Pocket，但它已经关闭了。这类经历让我对依赖单一商业服务始终保持警惕。可以预见的是，在相当长的一段时间里，我都会持续使用 Readeck；而自托管的好处在于，我不需要担心它哪天“倒闭”，从而突然失去这个服务。

## 用 Opencode 部署 Immich：让 Vibe coding 搞定你的自托管相册


下面我会展示：在你几乎不需要看文档、不需要写配置的情况下，如何用 **Opencode** 在飞牛 NAS 上完成 Immich 相册的部署。

### 第一步：安装 Opencode

通过 SSH 连接飞牛，或在飞牛系统中直接打开「终端」，执行：

```bash
curl -fsSL https://opencode.ai/install | bash
```

> 如果你更习惯 Claude Code，也可以使用：
> `curl -fsSL https://claude.ai/install.sh | bash`




安装完成后，把 opencode 加入环境变量：

```bash
export PATH="$PATH:$ HOME/.opencode/bin"
```

然后在终端中输入 `opencode`，即可启动。

### 第二步：配置免费模型

打开 opencode 后，按 `Ctrl + P` 切换大模型提供商。  
这里选择 **Opencode 官方**，并按提示访问 [https://opencode.ai/zen](https://opencode.ai/zen) 申请免费 API。

> 在当前网络环境下，Opencode 提供的免费模型（如 GLM 4.7 系列）已经**足够完成真实项目的 Docker 部署**。

### 第三步：一句话交给它做

在 opencode 终端中，直接输入你的需求：

> 帮我在我的飞牛 NAS 以 Docker 方式部署 immich（[https://github.com/immich-app/immich](https://github.com/immich-app/immich)），  
> Docker 文件保存在 `/vol1/1000/docker` 下的 `immich` 文件夹中，  
> 图片保存路径为 `/vol1/1000/Photos`

**不需要**：

- 通读 Immich 文档
    
- 手写 docker-compose
    
- 纠结目录结构
    
- 关心环境变量怎么配
    

你只需要做一件事：**提出目标，然后去做别的事**。

### 第四步：看它自己解决问题

Opencode 会开始思考并给出部署步骤。  
过程中你会看到它**主动遇到、并尝试解决**典型的网络问题：

> 拉取镜像失败 → 自动寻找国内可用镜像源 → 修改 compose 配置

如果是我们自己做，这一步往往意味着：

- 搜索“国内 Docker 镜像源”
    
- 反复试错
    
- 手动改配置
    

而在这里，Opencode 替你完成全部“踩坑过程”。

### 第五步：

它会根据你飞牛机器的实际情况：

- 自动配置正确路径
    
- 调整挂载参数
    
- 生成可用的 docker-compose 文件
    

    

等回来再看终端 —— **Immich 已经顺利启动**。

也许你具备一点点编程基础，知道一些基本的终端命令；也许你和大多数人一样，日常订阅着一堆软件，但你并不想成为开发者，更不想成为编程专家。你只是希望有一种方式，能够长期、稳定，并且按照你自己的方式，解决那些真实存在的需求。在这一点上，自托管 Docker 应用并不意味着“更复杂”，而是第一次让复杂性真正退居幕后。当你开始自托管时，你会发现自己第一次完整地掌控了所使用的应用。这种“拥有感”非常强烈，却又很难用一句话准确描述。我想，最直接、也是最可靠的方式，只有一个：亲自试一次。

当系统出问题时，我通过 SSH 登录，询问 Claude 或 Opencode 发生了什么，然后按它们给出的建议进行修复；当我想添加新的功能或服务时，只需要把需求描述清楚即可。我的时间开始重新回到“使用软件、学习和娱乐”上，而不再消耗在反复维护系统、担心订阅失效、功能被砍或价格上涨这些事情上。

**更多？**

订阅制应用的问题，除了无休止的付费外，并不在于“做得不够好”，而在于它们必须服务于一个足够大的用户群体和既定的商业模型，因此既无法、也没有动力去认真对待那些高度个人化的需求。你可以通过中文/英文作为编程语言与电脑进行沟通，管理和维护你的自托管应用，而这仅仅只是开始，但真正让我感到兴奋的是：在这个过程中，我已经隐约看到了未来的一丝曙光。这段时间里，我不断经历那种非常明确的 Aha moment。

举一个简单的例子。我一直非常喜欢 Things 3：它以“领域—项目”的方式来组织任务，并且提供了 Someday、晚间事项等清晰而克制的分类逻辑，这种设计精准地戳中了我的使用痛点。但与此同时，我也长期对 Things 3 对 Windows 用户几乎漠不关心的态度感到不满——直到今天，它依然没有提供 Windows 版本。冷静下来再看，做一个基于 Docker 的网页任务管理应用，其实并没有想象中那么困难。于是我把自己的需求写清楚，交给 _vibe coding_ 去完成。一个晚上睡醒后再回来，一个颇具 Things 3 风格的应用框架已经搭建完成，我可以直接在其中添加和管理不同的待办事项。

另一个例子，是一个用于提醒我定投的 Docker 服务。我希望有一个应用，每天在美股收盘时自动检查 SPY 的涨跌幅，同时具备简单的可视化和统计功能；如果当日跌幅超过 2%，就通过邮件提醒我进行当月定投。当然，这个逻辑完全可以进一步扩展为更复杂的策略，同时还能帮我统计历史定投记录和收益情况。这个需求，从描述到跑起来，只花了大约 20 分钟的 _vibe coding_。而它会长期、安静地运行在 NAS 的后台为我服务。
我常常在睡前把当天的想法整理出来，与 Claude Code 对话，确认需求，然后直接运行。还有一个非常有意思的插件：Ralph-wiggum（https://github.com/anthropics/claude-plugins-official/tree/main/plugins/ralph-wiggum）。Ralph 本质上就是一个 Bash 循环：一个 while true，不断把同一份任务说明书（提示词文件）喂给 AI agent，让它一轮一轮地改进实现，直到完成为止。等我第二天早上起床，再查看结果，往往就会迎来新的 Aha moment。

我越来越觉得，生活在现在这个 AI 起飞时代（无论是否存在泡沫）是一件很幸福的事情。而如今，像我这样的普通人，也终于能够真实而持续地体验到“创造”的乐趣。这在过去几乎难以想象——我竟然可以绕开那条漫长而陡峭的学习曲线，直接进入创造本身。

我的脑海里每天都会闪过大量想法。我可以随手用手机语音记录下来，与 AI 对话，把想法整理清楚，然后交给这些 _vibe coding_ 工具去实现：睡前提交，醒来验收。比如，我可以继续定制自己的 Memos，增加语音记录功能；利用 audiobookshelf 自动下载电子书和播客，再调用 Whisper 模型生成中文字幕，用大模型 API 进行多轮总结，最后自动推送到邮箱，由我决定听哪些内容。每一个流程、每一个节点，都可以按照自己的习惯和需求进行个性化定制。我是在站在无数优秀开源项目的肩膀上进行创造。在我眼中，网络上的代码仓库就像一个巨大的积木池。我们并不清楚想象力的边界在哪里，但在这个过程中，我们可以真正享受这种组合创造的乐趣，为自己拼出一套高度个性化、长期可用的自托管软件应用，而你，只需要逻辑清晰地书写需求即可。

我甚至隐约看到了未来：那种独立应用可以肆无忌惮推销订阅的时代，或许凋零。最近 _vibe coding_ 的进展神速，让苹果生态中的开发者数量显著增加；你也能在少数派这样的平台上，看到越来越多开发者开始推广自己的应用, 不得不感叹 _vibe coding_ 在悄悄地推动着世界进步。

Vibe coding 真的正在改变生活。相信技术发展，个性化应用真的不远。我从去年开始使用 Claude code 到现在的 openclaw，真的看到长足的进步。今天美股大跌就是因为 AI 正在抢占这些 SaaS 软件公司的市场，当然你说的维护和安全问题，这也是 AI vibe coding 面临的问题，AI vibe coding 又不会对服务和数据安全负责，但只要价格低和支付维护的溢价，那么就交给市场吧。
  除了 Cloudflare Tunnel 外，我没用过穿透软件，所以一直都很奇怪，穿透软件到底优势在哪里？
如果托管服务是给自己使用的话，比起加个穿透，以避免使用非 80 和 443 端口，在公网上直接加个端口的性能损耗更低的吧