點樣喺 VPS 上 self-host Hermes Agent

你好，我係 Lena。呢幾個月，我喺三台唔同嘅 VPS 上跑過 Hermes Agent self hosting，老實講，我嘅觀察係：將佢安裝到 server 上，大概二十分鐘就搞得掂。但要令佢 穩定跑幾個星期，唔需要你成日 babysitting，通常要反覆調幾輪。其實我到而家都唔肯定第三台機係咪真係調啱咗。呢篇 guide 講嘅就係呢個 gap——唔係 install 本身，而係由「works once」去到「我瞓覺時都信佢會繼續工作」中間嗰層慢慢磨出嚟嘅東西。

如果你只係需要官方 install path，Hermes Agent installation docs 已經涵蓋咗。呢篇講嘅係之後嘅事。

幾時 self-host Hermes 先有意思

Privacy、continuity、cost control、always-on workflows

講任何 server 嘢之前，先講清楚——self-hosting 係一種承諾，唔係捷徑。當你需要以下其中一樣或幾樣，佢先真正有意思：

Privacy. 你嘅 conversations、memories 同 skills 會留喺你控制嘅 infrastructure 上。API calls 仍然會出去到你配置好嘅 model provider，但圍繞住佢哋嘅一切——session history、user profile、workspace files——都會留喺本地。

Continuity. Laptop 一 sleep 或者合埋，本地 agent 就會停。VPS 唔會。如果你想 agent 喺凌晨 3 點回覆 Telegram message，或者跑一個你唔使開 terminal 嘅 scheduled cron job，你就需要將佢放喺另一個地方。

Cost control. Self-hosting 唔會降低 model costs——嗰部分係 provider 點樣收費就點樣計。佢改變嘅係 overhead：冇 seat licensing，冇 managed plan 嘅 per-user pricing，只有部機嘅成本加你嘅 provider tokens。

Always-on workflows. Gateway integrations（Telegram、Discord、Slack、messaging bots）只有喺 agent 一直 listening 嘅時候先有意義。cron jobs 都一樣。

如果以上都唔適用，而你只係夜晚喺 laptop 用 agent 三十分鐘，老實講——唔好 self-host。呢個 complexity 唔值得。

為 Hermes 揀 VPS 同 base OS

Minimum vs recommended specs

呢度我想反駁一下「runs on a $5 VPS」呢種講法。技術上係真。實際上好脆。 以下係我真實觀察到嘅情況：

1 vCPU / 1 GB RAM：會 boot。任何真實 workload 都會 crash。Python + Node + agent 自己嘅 processes 好快食晒 RAM，尤其 gateway 跑起之後。我試過有一台呢種機，喺一次 debugging session 入面直接 lock up。
2 vCPU / 2 GB RAM：對 CLI-only use, single user, no gateway 係可用嘅。仍然好緊。Swap 有幫助，但唔係 fix。
2 vCPU / 4 GB RAM：呢個係我現實使用中對 gateway + cron + light skills 嘅最低線。由呢度開始，事情先唔再咁 flaky。
2–4 vCPU / 8 GB RAM：multi-profile use、幾個 connected platforms，加上偶爾 heavy task，都會舒服好多，仲有 headroom。

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 一直 listening，而 cron 又不斷 fire scheduled jobs，你會有：

Constant memory residency（冇 garbage-collected idle state）
Continuous log volume
provider outages 期間可能越堆越多嘅 network retries
需要 survive restarts 嘅 file handles
service 必須讀得到嘅 secrets（API keys、tokens），唔可以只係你個 shell 先睇到

我唔肯定自己係咪完全讀啱，但我嘅印象係，大部分「my VPS keeps running out of memory」嘅 reports，其實都係「我用 interactive use 嘅配置去 size，然後開咗 gateway + 4 cron jobs」。要為 persistent load 做 plan，唔係為 empty load。

喺 server 上安裝同 harden Hermes

Service user、directory layout、updates、backups

唔好用 root 跑 Hermes。 呢點冇得傾。建立一個 dedicated user：

Bash

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

然後用呢個 user 去 install。所有嘢都會落喺 ~/.hermes/——config、sessions、memory、skills。呢個 directory 就係你嘅 state。要 backup。

我實際用嘅 backup 好 boring：

Bash

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

每星期用 cron 跑一次，將 tarball ship 去 box 外面（object storage、另一台 VPS，whatever）。你真正要保護嘅係 config.yaml、session database，同 MEMORY.md/USER.md。 Skills 可以由 hub recover。Memory 同 config 唔得。

Updates 方面：installer 有 update path。不過我學識咗 每次 update 前先 take a snapshot 或 backup，因為有時 update 會改 config schema，而我唔想喺 mid-conversation 先發現呢件事。如果你想 pull 前先睇 changelogs，version info 可以喺 Hermes Agent GitHub repository 見到。

Firewall：保持 VPS 嘅 public surface 盡量細。UFW 係最簡單嘅路——Ubuntu Server firewall documentation 講得幾清楚。我自己嘅 Hermes-only box 規則大概係：

Bash

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

就係咁。大部分 setups 入面，Hermes 唔需要任何 open inbound ports——gateway 係向 messaging platforms outward 連出去。如果你加 web UI，或者 expose 一個 local API，到時先開一個 specific port。

用 systemd 跑 gateway

呢一步會將一個 running process 變成 service。冇 systemd（或者類似嘅嘢），你個 SSH session 一死，hermes gateway 都會一齊死。我至少試過一次因為咁失去 Telegram bot，之後先真係寫咗 unit file。

下面係我用嘅形狀。儲存做 /etc/systemd/system/hermes-gateway.service：

TOML

[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

然後：

Bash

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 cleanly exit 而唔 auto-restart，on-abnormal 係另一個選擇。

另外——User=hermes 喺呢度真係有做嘢。唔只係 security。佢確保 service 會讀 hermes user 嘅 ~/.hermes/ directory，而唔係 root 嘅 directory（root 嗰個唔存在，然後你會見到一個好 cryptic 嘅 config error）。我第一次就係錯喺呢度。

如果想再 harden 個 unit file——NoNewPrivileges=true、ProtectSystem=strict、PrivateTmp=true——我唔喺呢度全部重寫，但 DigitalOcean 嘅 systemd units and unit files guide 有一個 production-style hardened example，值得照住 copy。

信任呢個 setup 之前要做嘅 production checks

Restart behavior、logs、provider failure、file persistence

喺我叫一台 box「done」之前，我會跑四個 checks。冇一個係 optional。我試過喺一台以為自己好熟嘅 machine 上 skip 咗，之後就後悔。

Restart survives a reboot.

Bash

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

如果 reboot 之後 service 唔係 active，即係你忘記咗 enable。而家就 fix。

Logs are readable and rotating.

Bash

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

重點係——喺 disk 填滿之前 set journal limits。Edit /etc/systemd/journald.conf，set SystemMaxUse=500M（或者任何適合你部 box 嘅值）。Arch Wiki's systemd journal page 對 rotation 同 vacuum options 嘅解釋，比好多 distro-specific docs 都詳細。我係試過一台 box 真係 disk entirely 滿晒先學識呢件事。唔好玩。

Provider failure is recoverable.

暫時整壞你嘅 API key（rename env var、revoke token，whatever）。經 gateway send 一個 message。service 會 crash 嗎？佢有冇 log error？你 restore key 之後佢會唔會 recover？

我嘅 baseline expectation 係：agent 應該 log 一個 clear error，然後繼續 running，而唔係死咗。 如果佢死，呢個係 operational problem，你會想而家發現，而唔係凌晨 3 點先知。

File persistence across restarts.

開一段 conversation。Send 一個 message。Restart service。Resume 個 session。Memory 有冇 carry across？session 有冇 survive？如果冇，check ~/.hermes/ permissions——呢個幾乎永遠係 user/group issue。

常見 VPS mistakes

Under-sizing RAM、weak logging、unsafe shell access、no rollback path

我最常見到嘅四個 failure modes，大概都係我自己踩過嘅順序：

Under-sized RAM。前面已經講咗。2 GB 係 floor，唔係 target。

Weak or unlimited logging. 如果你唔 configure journal size limits，你啲 logs 會食晒 disk。disk 滿咗之後，agent 會用好奇怪嘅方式 fail——config writes silently fail、skills save 唔到、sessions corrupt。第一日就 set limits。

Unsafe shell access for the agent. 如果你容許 agent execute arbitrary shell commands，terminal backend 設成 local，而你又用一個有 sudo rights 嘅 user 去跑，咁一次 mistake 嘅 blast radius 就係成部 machine。要麼用 terminal.backend=docker sandbox 佢，要麼用 dedicated user 並且冇 sudo。我自己兩樣都 prefer。

No rollback path. 一次 bad update，一次 bad config edit，你就會想有條路返轉頭。任何 major change 前 snapshot 個 VPS。保留最近三個 tarball backups。我用過。佢哋救過我。

FAQ

我需要 Docker 嗎？

唔一定需要，但如果你打算俾 agent 跑 arbitrary commands，我建議 terminal backend 用 Docker。Safer sandbox。

我可以喺一台 VPS 上跑 multiple profiles 嗎？

可以——hermes profiles create work，然後喺佢哋之間 switch。每個都有 isolated config、memory 同 skills。

我點樣 update 先可以冇 downtime？

嚴格嚟講唔得，但 downtime 好短。Stop service，pull update，restart。一兩分鐘。

gateway 同 CLI 可以同時跑嗎？

可以，只要佢哋喺同一個 profile。Sessions 係 shared。

如果我嘅 provider down 咗點算？

provider down 你冇咩可以做，但如果 Hermes 配置咗 provider fallback，佢會 try 下一個。如果你冇配置 fallback，gateway 會 cleanly error，等 provider 返嚟之後 recover。

我可能係諗多咗，但我一路返去嘅 pattern 係：VPS 唔係最難嗰部分。最難嘅係一個月 uptime 入面，慢慢、靜靜咁發現所有會出錯嘅地方。 呢個先係 self-hosting 真正嘅形狀。我會繼續睇住自己嘅 setup 點樣 behave，可能等我又整壞咗新嘢，就再 update 呢篇。今次就先寫到呢度。