Hermes AI Agent on AWS EC2

Running Hermes (or Openclaw) on your laptop is a category error. Hermes isn’t a chat app you open and close — it’s a 24/7 service that listens, routes, calls tools, and keeps working while you sleep. AWS EC2 gives it a home that does one thing well: stay up.

Why EC2 specifically?

Sleep mode kills agents. Network changes kill agents. Your laptop’s “quick tinker” energy kills agents. EC2 eliminates all three. You get a predictable Linux environment, SSH access, pay-per-use pricing, and the ability to scale from a t3.medium to something faster with a single click, something other VPS providers make surprisingly painful.

The separation matters too. When Hermes lives on EC2, failures are diagnosable. When it lives on your laptop, you can never tell if the bug is in the model, the channel bridge, or the fact that your MacBook went to sleep during a cron job.

The right mental model

Three layers, kept separate:

Agent layer: Hermes decides what a message means and what to do next
Channel layer: WhatsApp, Slack, Email: the front door
Tool layer: Scripts, Google Workspace, shell commands, cron jobs

Blur these together and debugging becomes a guessing game.

What to have ready before you start

An Ubuntu EC2 instance (t3.medium is a solid starting point)
SSH access or EC2 Instance Connect configured
Your model choice decided; not defaulted
External credentials ready, especially Google Workspace auth
A plan for persistence: service management, restart behavior, logs

The setup sequence

Provision the instance
Install Hermes per the official guide
Choose your model intentionally. I started with Gemini 2.5 Flash Lite; cheapest, and it showed. It kept misinterpreting simple repeated instructions. Moved to Gemini 2.5 Flash, which worked until it didn’t. I’m now running through my ChatGPT Plus subscription. I skipped Claude because it blocked subscription-based access and pushed toward API token pricing.
Set up one channel and test it fully. WhatsApp is easiest to start; Slack threads are better for contextual work (creating a new thread per task type beats managing WhatsApp groups)
Connect external tools only after the channel works
Persist the service so a reboot doesn’t wipe everything

The OAuth problem nobody warns you about

VPS setup is significantly harder than local setup for anything requiring OAuth. On your laptop, the browser handles everything. On EC2, there’s no browser. The workaround: complete the OAuth flow locally, grab the client_id, client_secret, and refresh_token from the resulting JSON, then transfer those files to the server. Use Claude or ChatGPT to debug configuration errors; you will hit them. Gemini was noticeably less useful for this.

The most common failure mode

You configure everything, create skills to automate tasks, it works — and then the next day Hermes has forgotten what to do with a prompt. The fix: make sure ~/.hermes/config.yaml has both system_prompts and channel-specific channel_prompts properly set. You have to explicitly tell Hermes what to do when it sees a trigger keyword. If it’s not in the config, it doesn’t exist.