The previous chapter walked through installation and initial setup. Now a different question comes up: where should Hermes live long-term? Your laptop? A rented server? A container?
The answer depends on what you want the agent to do. Hermes does not need a traditional deployment in the way a website does — there is no hosting platform, no CDN, no domain to point at it. But it does need a machine that is turned on and connected when you want it to work.
There are three practical paths, and they build on each other:
You are learning, testing, or running on-demand sessions where you sit at the keyboard and talk to the agent.
You need the gateway running 24/7 so the agent is reachable on Telegram, Slack, or Discord, or you have cron jobs that must run on schedule.
You want clean isolation from the host machine, easy teardown and rebuild, or a setup that runs identically on any server.
Start with local. Move to VPS when you need always-on services. Add Docker when you want reproducibility or isolation. The install command is the same everywhere — the difference is the machine it runs on.
Each path below covers what it is good for, what can go wrong, what to back up, what secrets are involved, how to know it is working, and when not to use it. Pick the one that matches your current situation.
Running Hermes on your laptop or desktop
What this is good for
Learning how Hermes works. Testing agent configurations. Running on-demand sessions at the terminal — you open a terminal, type hermes, and chat with the agent. Everything is in front of you: the files, the logs, the terminal output. The fastest way to go from installed to working.
What can go wrong
When your laptop sleeps, loses internet, or runs out of battery, the agent stops. Gateway and cron services only work while the machine is awake and connected. If you close the terminal, any running session ends. Background processes (gateway, cron) need a terminal or service manager to stay alive — otherwise they die when you log out.
What to back up
~/.hermes/.env (API keys — if you lose this, you must regenerate keys from your provider), ~/.hermes/config.yaml (provider and tool settings), ~/.hermes/memories/ (agent-curated facts), and ~/.hermes/skills/ (procedural knowledge). The source code in ~/.hermes/hermes-agent/ can be re-cloned; sessions can be rebuilt. But .env and config.yaml are the files you cannot reconstruct from memory if lost.
Secrets involved
Your model provider API key in ~/.hermes/.env. If you set up a messaging platform (Telegram bot token, Slack bot token, Discord bot token), those tokens also live in .env. These are the only secrets on a local install.
How to know it is working
Run hermes doctor. It checks your configuration, API key connectivity, tool availability, and data directory health. If everything passes, the agent is ready. Then type hermes and send a message — if the agent responds, the model provider is reachable and the runtime is working.
When not to use this path
Do not use local hosting if you need the agent reachable on a messaging platform while your laptop is closed, or if you have cron jobs that must run at specific times without you remembering to open a terminal. Those requirements need a machine that never sleeps — move to VPS or Docker on a server.
[Screenshot: Terminal showing hermes doctor output on a local install with all checks passing — config valid, API key reachable, tools available, data directory healthy.]
Some safety considerations are the same no matter where Hermes runs. These are the ones that catch people off guard:
Your .env file contains API keys and platform tokens. If it ends up in a Git repository — even a private one — it is a secret leak waiting to happen. Add .env to .gitignore in every project that touches the ~/.hermes/ directory.
Hermes uses file locks, but concurrent writers on the same state directory can cause corruption — especially for session history and cron job state. If you need multiple agents, use separate profiles (which isolate their data) or separate data directories entirely.
Before running hermes update, copy ~/.hermes/.env and ~/.hermes/config.yaml to a safe location. Updates are generally safe, but a config format change or a change in how providers are resolved could break your existing setup. A backup lets you roll back in minutes instead of rebuilding from scratch.
On a VPS or Docker setup where the gateway runs unattended, dangerous command approvals need careful configuration. The default approval mode is manual — which means no dangerous command runs unless someone approves it in real time. For unattended cron jobs, this means either using the smart approval mode (auxiliary LLM assesses risk) or restricting the agent's toolset so it cannot run dangerous commands at all. Chapter 14 covers this in detail.
Session logs, conversation history, and cron job output accumulate. On a VPS with limited storage, an unchecked log directory can fill the disk, causing silent failures. The disk-cleanup plugin shipped with Hermes can automate this — but you need to enable it.
One source of confusion: Hermes is a worker, not a website. If you have an agent that edits your website, the website still needs its own hosting (Netlify, Vercel, GitHub Pages, or a traditional server). Hermes does not replace that. Hermes is the worker that can make changes, open pull requests, run tests, and deploy — but the product it works on still lives where it has always lived.
Where the agent runtime lives. This is a VPS, a Docker container, or your laptop. It needs Python, an internet connection, and access to a model provider. It does not need to be publicly accessible — it reaches out to services, not the other way around (except for the gateway, which receives incoming messages).
Where the thing you are building lives. A website on Netlify. A code repository on GitHub. A database on AWS. Hermes can interact with all of these through tools and APIs, but it does not host them. If your website goes down, that is a product hosting problem, not a Hermes hosting problem.
This table summarizes the trade-offs. Use it as a decision guide, not a rulebook — your situation may not fit neatly into one cell.
| Consideration | Local | VPS | Docker |
|---|---|---|---|
| Cost | Free | $5–20/month | Same as host (free if local, VPS price if on server) |
| Always-on gateway | No — sleeps with laptop | Yes — 24/7 | Yes — if host is always-on |
| Cron jobs on schedule | Only while awake | Yes — unattended | Yes — if host is always-on |
| Setup complexity | Lowest | Medium (SSH, firewall, services) | Higher (volumes, Compose, permissions) |
| Isolation from host | None | Partial (own OS, but install touches system) | Full — container is sandboxed |
| Reproducibility | Manual | Manual | Built-in — same image everywhere |
| Debugging ease | Easiest — everything visible | Good — SSH access | Harder — must enter container or read logs |
| Best starting point | Yes | After learning locally | After you need reproducibility |
You have Hermes running on your laptop with a Telegram bot configured. The gateway works when you are at your desk, but messages go unanswered overnight. What needs to change, and which hosting path solves it?