Safe Hermes Updates on EC2
A cautious SSH-first routine for updating Hermes on an EC2 server, checking gateway health, and adding a quiet nightly update-available alert.
Hermes can update itself with one command, but a server running the Telegram gateway deserves a slower routine.
The rule is simple: check first, update from SSH, then verify the gateway from outside the chat session that depends on it.
Before updating
SSH into the EC2 box and check the installed version plus the local git state:
hermes --version
git -C ~/.hermes/hermes-agent status --short
If the git status is clean, continue.
If there are local changes, stop and decide what they are. Commit them, intentionally stash them, or back them up before updating. Do not let an update hide work you still need to understand.
Safe update routine
Run this from SSH into the EC2 server:
hermes update
hermes --version
hermes doctor
hermes gateway status
This checks four things:
- Hermes updated successfully.
- The version changed or is already current.
hermes doctorstill sees a healthy setup.- The gateway service is still reachable.
If the gateway service definition is outdated
Sometimes the code updates cleanly, but the installed gateway service definition is still old. If hermes gateway status says the service definition is outdated, restart the system service from SSH, not from inside Telegram:
sudo hermes gateway restart --system
hermes gateway status --system
journalctl -u hermes-gateway.service --since '10 minutes ago' --no-pager
This matters because a Telegram-served Hermes session depends on the gateway it is trying to restart. SSH gives you an outside control plane, so you can recover even if the gateway briefly disconnects.
Ongoing manual check
For a quick manual check, run:
hermes --version
When you want to know whether an update is available without installing it, run:
hermes update --check
That command checks for an update but does not apply it.
Optional nightly update alert
A good server routine should not auto-update Hermes while you sleep. It should alert only when the update check returns something other than the normal already-current result, so you can review it and run the safe SSH routine yourself.
Create a quiet watchdog script:
mkdir -p ~/.hermes/scripts
cat > ~/.hermes/scripts/check-hermes-update.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
output="$(hermes update --check 2>&1 || true)"
if grep -qi "already up to date" <<<"$output"; then
exit 0
fi
current="$(hermes --version 2>&1 || true)"
cat <<MSG
Hermes update may be available.
Current version:
$current
Update check output:
$output
Recommendation: SSH into the server and run the safe Hermes update routine.
MSG
EOF
chmod +x ~/.hermes/scripts/check-hermes-update.sh
Then schedule it for the night:
hermes cron create "0 3 * * *" \
--name "Hermes update check" \
--script check-hermes-update.sh \
--no-agent
With --no-agent, the script output is the alert. Empty output stays silent. That means you get a message only when the update check returns something other than the normal already-up-to-date result.
If you want the alert delivered to a specific platform or chat, add the appropriate --deliver target for your Hermes setup.
Operating principle
Separate discovery, update, and recovery:
- Discovery:
hermes update --check - Update:
hermes update - Health check:
hermes doctorandhermes gateway status - Recovery view:
journalctl -u hermes-gateway.service --since '10 minutes ago' --no-pager
That separation keeps the update boring. Boring is what you want for an agent that is also your control plane.