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.
Other helpful articles to setup & configure Hermes
- Hermes AI Agent Setup on AWS VPS
- Hermes WhatsApp Integration (coming soon)
- Hermes Slack Integration (coming soon)
- Hermes + Google Workspace CLI (coming soon)
- Choosing the Right Hermes Model Strategy (coming soon)
Further reading
- Hermes quickstart: official docs
- Messaging gateway: official docs
- Security model: official docs