4 July 2026
Why I Stopped Running Hermes on My Laptop and Moved It to a VPS
Hermes is built for persistence. The SOUL.md, the memory graph, the scheduled gateway tasks all of it assumes an agent that never sleeps. Running it on a laptop fundamentally contradicts that design. You get 60% of the value at best. The obvious fix is a VPS. A cheap Linux box running 24/7, Hermes installed, always listening. Simple in theory.
I run Hermes every day. It handles my Telegram messages, runs scheduled research tasks, and keeps context across sessions in a way no other agent does right now. For a few weeks I ran it locally on my machine and it worked fine until it didn't.
The moment I closed my laptop, Hermes went silent. Telegram messages went unanswered. Scheduled jobs missed their windows. Memory that Hermes had built up over days was still there when I reopened the session, but the continuity was gone. The agent that was supposed to be always on was only on when I was.
That is not an agent. That is a very smart chatbot with a good memory.
The Always On Problem
Hermes is built for persistence. The SOUL.md, the memory graph, the scheduled gateway tasks all of it assumes an agent that never sleeps. Running it on a laptop fundamentally contradicts that design. You get 60% of the value at best.
The obvious fix is a VPS. A cheap Linux box running 24/7, Hermes installed, always listening. Simple in theory.
In practice it takes longer than you would expect.
What It Actually Takes to Set Up Properly
I went through this myself. Here is what a proper Hermes VPS setup requires.
Provision a server and get Ubuntu 24.04 running. That part is easy. Then install the right version of Python, Node, and uv. Then run the Hermes installer, which is straightforward until it is not. The installer expects certain things about your environment that a fresh VPS does not always have. Then configure your model provider, get your API key in the right place, and test that Hermes actually starts.
Then you want it to survive reboots. That means setting up a systemd service. Then you want the web GUI accessible from your browser without exposing an unauthenticated port to the internet. That means nginx, a reverse proxy, certbot for SSL, and basic auth. Then you realise the nginx config needs specific headers or the web GUI rejects requests with an invalid host error.
None of this is hard if you know Linux. But it is time consuming, and there are enough gotchas that most people either gave up halfway or ended up with a working but insecure setup.
What a Properly Configured Setup Looks Like
When it is done right here is what you get.
Hermes running as a dedicated system user with its own home directory and sudo access scoped correctly. A systemd service that starts on boot and restarts automatically if Hermes crashes. The web GUI running on localhost only, proxied through nginx with a real SSL certificate from Let's Encrypt and basic auth protecting it from the public internet. Your SSH key on the server so you can drop in from anywhere. Fail2ban blocking brute force attempts. UFW configured to allow only SSH, HTTP, and HTTPS.
That setup runs reliably. I have had one running for weeks without touching it.
For Those Who Would Rather Not Touch the Terminal
If you want Hermes running on a dedicated VPS without any of the above, that is what hermes.fast is for. You pick a plan, add your SSH key, and your server is provisioned automatically with Hermes pre-installed, your subdomain configured, SSL set up, and the web GUI ready to go.
Either way, get Hermes off your laptop. It is a different product when it never sleeps.