Running Hermes in a container makes it always-on, reproducible and isolated — but it also introduces one way to lose everything your agent has learned. Here’s what has to persist, what should never go in the image, and whether you actually need a container at all.
Short answer
- Containers give you always-on, reproducible and isolated — a plain server only gives you the first.
- Mount memory, skills, personas, profiles and cron jobs, or a rebuild wipes your agent.
- Never bake credentials into the image — Hermes strips them from its own exports for the same reason.
- Export before every rebuild, and put a spending cap on anything running unattended.
Why put Hermes in a container
Hermes runs fine on your laptop. The reasons to containerise it are about what happens when your laptop isn’t the right place for it to live.
- It keeps running when you close the lid. An agent on your laptop stops when your laptop stops. In a container on a server, it doesn’t.
- The setup becomes reproducible. Same image, same behaviour, whether it’s your machine, a VPS or a colleague’s box.
- It’s isolated. Hermes runs real commands with real permissions. A container puts a boundary around what it can touch.
- It’s disposable. Something goes wrong, you rebuild from the image rather than unpicking what changed.
- You can run several. Separate containers for separate agents or clients, with no chance of one bleeding into another.
That third point is the one I’d weight most heavily. Hermes executes commands on the machine it’s on. Everywhere else I’ve written about it I’ve said keep approvals on — a container is the structural version of the same caution.
What actually needs to persist
This is where containerised agents go wrong. A container is disposable; your agent shouldn’t be. Before you build anything, know what has to survive a rebuild.
| What | Why it matters |
|---|---|
| Memory | The most valuable part of your agent — it came from your history together and can’t be rebuilt from scratch |
| Skills | Abilities it worked out and wrote down as markdown |
| Persona / SOUL.md | How it talks and behaves |
| Profiles | Each one its own isolated setup, config and history |
| Cron jobs | The schedules that make it work while you’re not there |
| Credentials | Which should be injected at runtime, never baked into an image |
Mount those as volumes. If you don’t, you’ll rebuild the container one day and discover your agent has amnesia — which is the exact failure the export and import commands exist to prevent. Worth reading the backup and restore guide before you containerise anything, because a working export is your safety net.
🔥 Want this set up without the guesswork? Running an agent somewhere it stays up, without it becoming a maintenance job of its own, is the part people underestimate. Inside the AI Profit Boardroom you get the Agent OS as a ready-to-install file, a 30-day roadmap, daily tutorials the same day new tools ship, and four live coaching calls a week where you share your screen and get unstuck. → Get access here
Never bake credentials into the image
Worth its own section because it’s the mistake with the worst consequences.
Your API keys and tokens should be injected at runtime — environment variables, a secrets mount, whatever your platform offers. Not committed into the image, not in a file that ends up in a layer.
Hermes itself already takes this position: when it exports an agent profile, credentials are stripped out automatically so the file is safe to hand to someone else. Follow the same logic with your images. The agent’s brain travels; your access shouldn’t.
If an image with keys baked in ever leaves your machine, you’re not rotating one key — you’re rotating everything it could reach.
Local, server or container: which do you actually need?
| Setup | Best for | Trade-off |
|---|---|---|
| Laptop, no container | Learning it, daily interactive use | Stops when your laptop stops |
| Server, no container | Always-on with minimal fuss | Setup drift, harder to reproduce |
| Container on a server | Always-on, reproducible, isolated | You maintain the image |
| Several containers | Multiple agents or client separation | More moving parts |
Be honest about which problem you actually have. If you just want your agent running overnight, a small VPS gets you most of the benefit — see installing Hermes on a server. Containers earn their keep when you need reproducibility or isolation on top of that.
One thing to note if you use the desktop app: Bot Mode is a desktop plugin and installs on the machine running the desktop app, not on your server. The gateway can live remotely and the desktop connects to it — but people have installed the plugin server-side and seen nothing.
Practical notes before you start
- Get it working uncontainerised first. Debugging a new setup and a new container at the same time is how afternoons disappear.
- Mount the data directories so memory, skills, profiles and cron jobs live outside the container.
- Inject secrets at runtime. Never in the image.
- Export before you rebuild. One command, and it’s your insurance.
- Decide on models before you deploy. A container on a server pointed at a paid API can run up a bill unattended in a way a laptop session never does.
- Set the budget caps. Anything unattended needs a ceiling — that’s true of cron jobs and loops too.
That last pair matters more than the container work itself. The whole point is that it runs without you watching, which is also the whole risk.
Want it running around the clock without babysitting it? The Agent OS in the AI Profit Boardroom covers the always-on setup — memory, cron jobs, profiles and the dashboard — with the install file, a 30-day roadmap, daily tutorials and four coaching calls a week where you can bring your own deployment. Start free with the free AI course and community.
FAQ
Can you run Hermes Agent in Docker?
Yes, and it’s a sensible choice when you want it always-on, reproducible and isolated. The key is mounting the data directories so memory and skills survive a rebuild.
What do I need to persist?
Memory, skills, personas, profiles and cron jobs. Those are what took time to build and can’t be recreated from an image.
Should I put my API keys in the image?
No. Inject them at runtime. Hermes strips credentials from its own profile exports for the same reason — the brain should travel, the access shouldn’t.
Do I need a container just to run it 24/7?
No. A small server gets you always-on. Containers add reproducibility and isolation on top, which is a different problem.
Does Bot Mode work in a container?
Bot Mode is a desktop plugin that installs on the machine running the desktop app, not your server. The gateway can live remotely and the desktop connects to it.
How do I avoid losing my agent on a rebuild?
Mount your data as volumes, and run an export first. Export packages persona, skills, memory and cron jobs into one file you can import anywhere.
Is a container safer?
It puts a boundary around an agent that runs real commands with real permissions. It’s a structural safeguard, not a substitute for keeping approvals on.
What should I watch once it’s unattended?
Cost. A container pointed at a paid API can run up a bill overnight in a way an interactive laptop session never will. Set caps.
The bottom line
A Hermes agent Docker setup is worth it when you need always-on, reproducible and isolated — not just to keep it running overnight, which a plain server already does. Mount memory, skills, profiles and cron jobs as volumes, inject credentials at runtime rather than baking them in, export before every rebuild, and put a spending cap on anything that runs while you’re asleep.
About Julian Goldie
I run Goldie Agency, a 7-figure SEO agency, and teach this daily on a 400K+ subscriber YouTube channel. 240+ client projects on Upwork at a 100% job-success score, 10+ years through every major Google update. My systems are in the AI Profit Boardroom; my link building book is free here.