如何在 VPS 上自托管 Hermes Agent

你好，我是 Lena。这几个月里，我在三台不同的 VPS 上跑过 Hermes Agent self hosting，我最真实的观察是：把它 安装 到服务器上，大概二十分钟就够了。但要让它 稳定跑上好几周，不需要人一直盯着，通常要反复调几轮。说实话，我到现在也不确定第三台机器是不是已经调对了。这篇指南讲的就是这个空隙——不是安装本身，而是从"跑起来一次"到"我睡觉时也相信它会继续工作"之间那层慢慢磨出来的东西。

如果你只需要官方安装路径，Hermes Agent installation docs 已经写得很清楚了。这篇文章讲的是之后发生的事。

什么时候适合自托管 Hermes

隐私、连续性、成本控制、常驻工作流

在进入服务器细节之前，先说一句——self-hosting 是一种承诺，不是捷径。只有当你需要下面一项或多项时，它才真的有意义：

隐私。 你的对话、记忆和 skills 留在你控制的基础设施上。API calls 仍然会发到你配置的 model provider，但围绕它们的一切——session history、user profile、workspace files——都留在本地。

连续性。 笔记本一休眠或合上，本地 agent 就停了。VPS 不会。如果你希望 agent 在凌晨 3 点回复 Telegram 消息，或者跑一个你不用打开 terminal 的定时 cron job，那它就需要待在别的地方。

成本控制。 Self-hosting 不会降低 model costs——那部分还是 provider 怎么收费就怎么来。它改变的是 overhead：没有 seat licensing，没有 managed plan 的 per-user pricing，只有机器成本加上你的 provider tokens。

常驻工作流。 Gateway integrations（Telegram、Discord、Slack、messaging bots）只有在 agent 一直监听时才有意义。cron jobs 也是一样。

如果这些都不适用，而你只是晚上用笔记本打开 agent 半小时，老实说——别 self-host。复杂度不值得。

为 Hermes 选择 VPS 和基础 OS

最低配置 vs 推荐配置

这里我想稍微反驳一下"能跑在 $5 VPS 上"这种说法。技术上没错。实际使用很脆。 这是我自己观察到的情况：

• 1 vCPU / 1 GB RAM：能启动。任何真实 workload 下都会崩。Python + Node + agent 自己的 processes 很快就吃掉 RAM，尤其 gateway 跑起来之后。我有一台这样的机器，在一次 debugging session 里直接卡死。
• 2 vCPU / 2 GB RAM：对于 CLI-only use, single user, no gateway 勉强可用。还是很紧。Swap 有帮助，但不是修复方案。
• 2 vCPU / 4 GB RAM：这是我在真实环境里给 gateway + cron + light skills 的最低线。从这里开始，系统才不再感觉摇摇欲坠。
• 2–4 vCPU / 8 GB RAM：多 profile 使用、连接多个平台、偶尔跑重任务，都比较舒服，也有余量。

Base OS：Ubuntu 22.04 or 24.04 LTS. 我两个都在用。Debian 12 也没问题。其他系统的话，dependency edge cases 就要你自己处理了。

Storage：30–40 GB 对 agent 本身足够了。Session databases 增长很慢——活跃使用大概每月 50 MB。真正可能吓你一跳的是 logs，后面我会讲。

gateway 和 cron 持续运行后会发生什么变化

这部分我差点是用最痛的方式才学会的。交互式运行 Hermes，和把它作为 persistent service 运行，是两件事。 当 gateway 一直监听、cron 不断触发 scheduled jobs 时，你会面对：

• 常驻内存占用（没有被垃圾回收掉的 idle state）
• 持续增长的 log volume
• provider outage 期间可能堆起来的 network retries
• 需要跨重启存活的 file handles
• service 能访问的 secrets（API keys、tokens），而不是只在你的 shell 里可见

我不确定自己理解得是否完全准确，但我的感觉是，大多数"我的 VPS 一直内存不够"的报告，本质上都是"我按交互式使用配了机器，然后打开了 gateway + 4 个 cron jobs"。要按持续负载来规划，而不是按空载来规划。

在服务器上安装并加固 Hermes

service user、目录布局、更新、备份

不要用 root 跑 Hermes。 这是唯一不能让步的点。创建一个专门的 user：

sudo adduser hermes
sudo usermod -aG docker hermes   # only if you plan to use the Docker terminal backend

然后用这个 user 安装。所有东西都会落在 ~/.hermes/——config、sessions、memory、skills。这个目录 就是 你的状态。要备份它。

我实际用的备份方式很无聊：

tar -czf hermes-backup-$(date +%F).tar.gz ~/.hermes/

每周用 cron 跑一次，把 tarball 发到机器外面（object storage、另一台 VPS，随便什么都行）。你真正要保护的是 config.yaml、session database，以及 MEMORY.md/USER.md。 Skills 可以从 hub 恢复。Memory 和 config 不行。

更新方面：installer 自带 update path。但我已经养成了 任何 update 之前先做 snapshot 或 backup 的习惯，因为偶尔 update 会改 config schema，而我不想在对话进行到一半时才发现这件事。如果你想在 pull 之前看 changelogs，version info 可以在 Hermes Agent GitHub repository 里看到。

Firewall：尽量让 VPS 的 public surface 保持最小。UFW 是最简单的路径——Ubuntu Server firewall documentation 讲得不错。我给 Hermes-only box 配的规则大概是这样：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

就这些。大多数 setup 下，Hermes 不需要任何开放的 inbound ports——gateway 是向 messaging platforms outward 连接。如果你加 web UI，或者在本地暴露 API，那时再只开放某个具体端口。

用 systemd 运行 gateway

这一步会把一个正在跑的 process 变成 service。没有 systemd（或等价工具），你的 SSH session 一断，hermes gateway 也就死了。我至少因此弄丢过一次 Telegram bot，后来才真的去写 unit file。

这是我用的基本形状。保存为 /etc/systemd/system/hermes-gateway.service：

[Unit]
Description=Hermes Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hermes
Group=hermes
WorkingDirectory=/home/hermes
ExecStart=/home/hermes/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

然后：

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-gateway
sudo systemctl status hermes-gateway

有几个细节，我希望自己更早知道。Restart=on-failure + RestartSec=10 是最低配置。 没有它，任何 transient error 都会让 service 永久退出。systemd.service manual page 列出了完整的 restart policies——如果你希望允许 service 主动干净退出而不自动重启，on-abnormal 是另一个选择。

另外——User=hermes 在这里真的有作用。不只是安全。它确保 service 从 hermes user 的 ~/.hermes/ 目录读取，而不是从 root 的目录读取（后者不存在，于是你会得到一个很隐晦的 config error）。我第一次就错在这里。

如果还想进一步加固 unit file——NoNewPrivileges=true、ProtectSystem=strict、PrivateTmp=true——我就不在这里全部复述了，但 DigitalOcean 的 systemd units and unit files guide 有一个 production-style hardened example，很值得照着抄。

在信任这个 setup 之前做 production checks

重启行为、logs、provider failure、文件持久化

在我把一台机器叫做"done"之前，我会跑完四项检查。没有一项是可选的。我曾经在一台自以为很熟的机器上跳过它们，然后后悔了。

1. Restart survives a reboot.

sudo reboot
# wait, then:
ssh back in
systemctl status hermes-gateway

如果 reboot 之后 service 不是 active，那就是你忘了 enable。现在就修。

2. Logs are readable and rotating.

journalctl -u hermes-gateway -n 100
journalctl -u hermes-gateway --since "1 hour ago"

重点是——在磁盘被填满之前设置 journal limits。编辑 /etc/systemd/journald.conf，设置 SystemMaxUse=500M（或任何适合你机器的值）。Arch Wiki's systemd journal page 对 rotation 和 vacuum options 的解释，比大多数 distro-specific docs 都详细。我是因为一台机器真的把磁盘跑满了才学到这个。不好玩。

3. Provider failure is recoverable.

临时弄坏你的 API key（改掉 env var 名字、revoke token，随便一种）。通过 gateway 发一条消息。service 会 crash 吗？会记录 error 吗？你恢复 key 之后它能恢复吗？

我的 baseline expectation 是：agent 应该记录清晰 error 并继续运行，而不是直接死掉。 如果它死了，那你遇到的是 operational problem，最好现在发现，而不是凌晨 3 点发现。

4. File persistence across restarts.

进行一段对话。发一条消息。重启 service。继续这个 session。Memory 还在吗？session 还活着吗？如果不在，检查 ~/.hermes/ permissions——这几乎总是 user/group 问题。

常见 VPS 错误

RAM 配太小、logging 太弱、不安全的 shell access、没有 rollback path

我最常看到的四种 failure modes，大致也是我自己踩过的顺序：

Under-sized RAM。前面已经讲过。2 GB 是底线，不是目标。

Weak or unlimited logging. 如果不配置 journal size limits，你的 logs 会吃掉磁盘。磁盘满了以后，agent 会以很奇怪的方式失败——config writes 静默失败、skills 无法保存、sessions 损坏。第一天就把 limits 配好。

Unsafe shell access for the agent. 如果你允许 agent 执行任意 shell commands，terminal backend 又设成 local，同时运行它的 user 还有 sudo rights，那一次错误操作的 blast radius 就是整台机器。要么用 terminal.backend=docker 做 sandbox，要么放在一个没有 sudo 的 dedicated user 下跑。我更倾向两个都做。

No rollback path. 一次坏 update，一次坏 config edit，你都会想要一条回去的路。任何 major change 之前先 snapshot VPS。保留最近三个 tarball backups。我用过它们。它们真的救过我。

FAQ

我需要 Docker 吗？

不是必须，但如果你要让 agent 运行任意 commands，我建议 terminal backend 用 Docker。更安全的 sandbox。

我能在一台 VPS 上跑多个 profiles 吗？

可以——hermes profiles create work，然后在它们之间切换。每个 profile 都有隔离的 config、memory 和 skills。

怎样 update 才能不停机？

严格说做不到，但 downtime 很短。停 service，pull update，重启。一两分钟。

gateway 和 CLI 可以同时跑吗？

可以，只要它们在同一个 profile 上。Sessions 是共享的。

如果我的 provider 挂了怎么办？

provider 挂了你没什么能做的，但如果 Hermes 配了 provider fallback，它会尝试下一个。如果没配 fallback，gateway 会清晰地报错，并在 provider 恢复后恢复。

我可能想太多了，但我一直回到的那个模式是：VPS 不是难的部分。难的是在一个月 uptime 里，慢慢、安静地发现所有可能出错的东西。 这大概就是 self-hosting 的形状。我会继续观察自己的 setup 怎么表现，可能等我又弄坏什么新东西时再来更新。今天就先写到这里。

Previous Posts:

• Hermes Agent Observability: Why HUD Matters for Production Agents
• Hermes Agent vs EvoMap Agent Memory: What Actually Persists Across Runs
• Claude Usage Limits and Agent Failures: How to Fix Common Outages
• Agent Hooks and Execution Chains: How AI Agents Actually Run Tasks
• OpenHarness and GEP: Understanding the Agent Stack Layers