VPS で Hermes Agent を self-host する方法

こんにちは、Lena です。この数か月、私は 3 台の別々の VPS で Hermes Agent self hosting を動かしてきました。正直な観察としては、server に install するだけなら、たぶん 20 分くらいで終わります。でも、何週間も安定して動き続け、babysitting がいらない状態 にするには、何度か調整を重ねる必要がありました。実は、3 台目の box もまだ本当に正しく仕上がっているのか、少し自信がありません。この guide が扱うのはその隙間です。install そのものではなく、「一度動いた」から「寝ているあいだも動き続けると信頼できる」までの、ゆっくりした層の話です。

公式の install path だけが必要なら、Hermes Agent installation docs にまとまっています。この記事は、その後に来るものです。

Hermes を self-host する意味があるとき

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 — は local に残ります。

Continuity. laptop は sleep したり閉じたりすると、local agent も止まります。VPS は止まりません。午前 3 時に agent に Telegram message へ返答してほしい、あるいは terminal を開かなくても scheduled cron job を走らせたい。そういう場合、agent は別の場所にいる必要があります。

Cost control. Self-hosting は model costs を下げません。そこは provider の料金どおりです。変わるのは overhead です。seat licensing も、managed plan の per-user pricing もなく、box の費用と provider tokens だけになります。

Always-on workflows. Gateway integrations（Telegram、Discord、Slack、messaging bots）は、agent が常に listening しているときにだけ意味があります。cron jobs も同じです。

どれにも当てはまらず、夜に laptop から 30 分だけ agent を使うだけなら、正直に言うと self-host しないほうがいいです。その複雑さに見合いません。

Hermes 用の VPS と base OS を選ぶ

Minimum vs recommended specs

ここでは、「$5 VPS で動く」という言い方に少しだけ反論したいです。技術的には正しい。実務上はかなり脆い。 私が実際に見た感覚はこうです。

1 vCPU / 1 GB RAM：boot はします。実際の workload では落ちます。Python + Node + agent 自身の processes は、特に gateway が動き始めると RAM をすぐに食います。私はこの構成の 1 台を、たった 1 回の debugging session 中に固まらせました。
2 vCPU / 2 GB RAM：CLI-only use, single user, no gateway なら使えます。それでもかなり tight です。Swap は助けになりますが、fix ではありません。
2 vCPU / 4 GB RAM：gateway + cron + light skills に対する、私の現実的な最低ラインです。このあたりから、flaky さが少し消えます。
2–4 vCPU / 8 GB RAM：multi-profile use、複数の connected platforms、たまに重い task を走らせる用途でも、余裕があります。

Base OS: Ubuntu 22.04 or 24.04 LTS. 私は両方使っています。Debian 12 も問題ありません。それ以外は、dependency edge cases を自分で見ることになります。

Storage: agent 自体には 30–40 GB で十分です。Session databases はゆっくり増えます。active use で月 50 MB くらいかもしれません。意外に効いてくるのは logs です。ここには後で戻ります。

gateway と cron が継続的に動くと何が変わるか

ここは、私はもう少しで痛い方法で学ぶところでした。Hermes を interactively に動かすことと、persistent service として動かすことは別物です。 gateway が常に listening し、cron が scheduled jobs を発火し続けると、次のものが出てきます。

Constant memory residency（garbage-collected idle state がない）
Continuous log volume
provider outages のあいだに積み上がる network retries
restarts をまたいで生き残る必要がある file handles
shell だけでなく service からもアクセスできる secrets（API keys、tokens）

私の読み方が正しいかは少し自信がありません。でも、「my VPS keeps running out of memory」という報告の多くは、実際には「interactive use 向けに size して、その後 gateway + 4 cron jobs を有効化した」ものではないか、という印象があります。空の負荷ではなく、persistent load に合わせて計画したほうがいいです。

server 上で Hermes を install し、harden する

Service user、directory layout、updates、backups

Hermes を root で動かさない。 ここだけは譲れません。専用 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 はかなり地味です。

Bash

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

これを weekly に cron で走らせ、tarball を box の外へ送ります（object storage、別の VPS、何でもいいです）。守りたいものは config.yaml、session database、そして MEMORY.md/USER.md です。 Skills は hub から復元できます。Memory と config はそうはいきません。

Updates については、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 なら、私の rules はだいたいこうです。

Bash

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

これだけです。多くの setup では、Hermes に open inbound ports は必要ありません。gateway は messaging platforms へ outward に接続します。web UI を追加する、あるいは API を local に expose するなら、そのときだけ specific port を開けます。

systemd で gateway を動かす

ここで、running process が service になります。systemd（または同等のもの）がないと、SSH session が死んだ瞬間に hermes gateway も死にます。私は実際に unit file を書く前、少なくとも一度 Telegram bot をこれで失いました。

私が使っている形はこうです。/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 が root の ~/.hermes/ ではなく、hermes user の ~/.hermes/ directory を読むようにするためです。root 側には存在せず、そうすると cryptic な config error が出ます。私は最初にこれを間違えました。

unit file をさらに harden するなら、NoNewPrivileges=true、ProtectSystem=strict、PrivateTmp=true などがあります。ここですべては再掲しませんが、DigitalOcean の systemd units and unit files guide には production-style hardened example があり、参考にする価値があります。

setup を信頼する前の production checks

Restart behavior、logs、provider failure、file persistence

私が box を「done」と呼ぶ前に、必ず 4 つの checks を通します。どれも optional ではありません。分かっているつもりの machine で skip して、後悔したことがあります。

Restart survives a reboot.

Bash

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

reboot 後に service が active でなければ、enable を忘れています。今直します。

Logs are readable and rotating.

Bash

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

大事なのは、disk が埋まる前に journal limits を設定することです。/etc/systemd/journald.conf を編集し、SystemMaxUse=500M（または box に合う値）を設定します。Arch Wiki's systemd journal page は、rotation と vacuum options を多くの distro-specific docs より詳しく説明しています。私は 1 台の box で disk を完全に埋めてしまって、これを学びました。楽しくはありません。

Provider failure is recoverable.

一時的に API key を壊します（env var を rename する、token を revoke する、何でもいいです）。gateway 経由で message を送ります。service は crash しますか。error を log しますか。key を戻したら recover しますか。

私の baseline expectation は、agent は clear error を log して動き続けるべきで、死ぬべきではないというものです。死ぬなら、それは operational problem です。午前 3 時ではなく、今見つけたい問題です。

File persistence across restarts.

conversation をします。message を送ります。service を restart します。session を resume します。memory は引き継がれますか。session は残っていますか。残っていなければ、~/.hermes/ permissions を確認します。ほとんどの場合、user/group issue です。

よくある VPS mistakes

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

私がよく見る 4 つの failure modes は、だいたい私自身が踏んだ順番でもあります。

Under-sized RAM。これはすでに触れました。2 GB は floor であって、target ではありません。

Weak or unlimited logging. journal size limits を設定しないと、logs が disk を食い尽くします。disk がいっぱいになると、agent は変な壊れ方をします。config writes が静かに失敗し、skills が保存できず、sessions が corrupt します。初日に limits を設定してください。

Unsafe shell access for the agent. terminal backend を local にして、agent に arbitrary shell commands の実行を許し、さらに sudo rights のある user で動かしているなら、mistake の blast radius は machine 全体です。terminal.backend=docker で sandbox するか、sudo のない dedicated user で動かします。私は両方を好みます。

No rollback path. 1 回の bad update、1 回の bad config edit で、戻る道がほしくなります。major change の前には VPS の snapshot を取ります。直近 3 つの tarball backups を残します。私は使ったことがあります。本当に助かりました。

FAQ

Docker は必要ですか？

必須ではありません。ただし、agent に arbitrary commands を実行させるなら、terminal backend には Docker をおすすめします。より安全な sandbox になります。

1 台の VPS で multiple profiles を動かせますか？

はい。hermes profiles create work を実行し、その後それらを切り替えます。それぞれ isolated config、memory、skills を持ちます。

downtime なしで update できますか？

実際には難しいですが、downtime は短いです。service を止め、update を pull し、restart します。1〜2 分くらいです。

gateway と CLI を同時に動かせますか？

はい。同じ profile 上であれば大丈夫です。Sessions は共有されます。

provider が落ちたらどうなりますか？

provider についてはできることがあまりありません。ただし Hermes に provider fallback を設定していれば、次を試します。fallback を設定していない場合、gateway は cleanly に error を出し、provider が戻ると recover します。

考えすぎかもしれません。でも、私が何度も戻ってくる pattern はこれです。VPS は難しい部分ではありません。難しいのは、1 か月の uptime のなかで、何が壊れうるのかをゆっくり静かに見つけていくことです。 それが self-hosting の形なのだと思います。自分の setup がどう振る舞うか、これからも見続けます。そして、たぶんまた何かを壊したら、この記事を更新します。今回はここまでにします。