.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Most migration guides assume you're moving from A to B in one motion. In practice, plenty of people want to keep their old OpenClaw setup running while they trial Hermes for a month. Two reasons usually drive that. First is the safety-net argument: if Hermes does something unexpected, OpenClaw is right there as a known-working baseline to compare against. Second is the integration argument: maybe one specific OpenClaw skill is mission-critical and you don't want to migrate it until you've verified the Hermes equivalent is at least as good.
Running both at the same time is fine. The two agents don't fight over anything except resources. Even there the conflict is mild because Hermes and OpenClaw are mostly idle between requests. The real work in keeping them coexistent is housekeeping: separate data directories, separate ports, separate bot tokens, separate systemd units. None of it is hard. All of it has to be deliberate.
What collides if you don't think about it
Six things can step on each other if you install Hermes onto a server that already runs OpenClaw.
The first is the data directory. OpenClaw writes to ~/.openclaw/, Hermes to ~/.hermes/. These don't overlap by default, so this one is fine without intervention.
The second is the bot tokens. Telegram (and Discord plus any other chat platform) routes incoming messages to whichever client is currently polling for them. If you point both OpenClaw and Hermes at the same Telegram bot token, each message gets delivered to one of them at random. The user-visible symptom is that your bot starts answering with two personalities. The fix is to register a second Telegram bot via BotFather and give one to each agent.
The third is bound ports. The Hermes dashboard, the gateway HTTP listener and any inbound webhooks all bind to ports. OpenClaw has its own equivalents. If both pick the same default port, the second to start fails with "address already in use". The fix is to set explicit, non-overlapping port choices.
The fourth is the systemd unit names. If both agents register a service called agent.service, only one of them works. Use distinct names: openclaw.service and hermes.service.
The fifth is API rate limits at your LLM provider. If both agents are using the same OpenAI or OpenRouter key, they share the rate limit. Two agents at full tilt can blow through a free or starter tier in a way one agent on its own wouldn't. Either keep them on different providers or accept that you'll occasionally see throttling.
The sixth is browser automation, if you use it. Both agents can launch a Playwright or Camofox session, but they each want their own profile directory. The fix is to set BROWSER_PROFILE_DIR (or the equivalent config key) per agent so they don't fight over the same Chrome state.
The setup that works for me
Here's what I have running on a 4 GB Ubuntu 24.04 VPS, both agents active, no collisions for about six weeks.
OpenClaw is the existing setup. It listens on port 7000 internally, runs as a non-root user (openclaw), uses systemd unit openclaw.service and points at @MyName_OpenClawBot on Telegram with key OPENCLAW_TG_TOKEN in ~/.openclaw/.env.
Hermes is the new setup. It runs as $USER, listens on port 9119 (the Hermes default), uses systemd unit hermes.service and points at @MyName_HermesBot on Telegram with key TELEGRAM_BOT_TOKEN in ~/.hermes/.env.
Both agents share OpenRouter for cheap calls. I keep an eye on the rate limit, but with my actual usage (a few dozen messages a day across both bots), I've never hit it.
Step by step, what to do on a VPS that already runs OpenClaw
Start by writing down what your current OpenClaw setup looks like. The systemd unit file, the .env path, the port, the bot token, the data directory. You'll want this list as a reference when you configure Hermes to avoid all of the above.
On the OpenClaw side, no changes are required if your unit and ports are already set. If the OpenClaw gateway runs on the Hermes default port (some old setups did), move it now to a non-default port (anything between 7000 and 8500 is fine) and update its systemd file to match.
Install Hermes following the Ubuntu install guide. If you're on a fresh LumaDock VPS with the Hermes template, the VPS setup guide walks the first-login menu instead. The installer drops everything into ~/.hermes/, which doesn't conflict with OpenClaw's ~/.openclaw/ in any way. The hermes binary lands in ~/.local/bin/hermes, not /usr/local/bin/openclaw, so they don't fight on PATH either.
Run hermes setup. When the wizard asks for a Telegram bot, give it the token for the new bot you registered for Hermes. Don't reuse OpenClaw's. If you don't have a second bot yet, open Telegram, message @BotFather, send /newbot, pick a name and pick a username (Telegram usernames must be unique globally; my_hermes_bot_2026 or similar works fine). Copy the token BotFather gives you back into the Hermes wizard.
Wire up the systemd unit. The systemd guide has the long version, but for two-agent setups the bit that matters is the unit filename. Don't reuse agent.service from your OpenClaw days. Call it hermes.service:
[Unit]
Description=Hermes Agent
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=youruser
ExecStart=/home/youruser/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=5
Environment="HOME=/home/youruser"
[Install]
WantedBy=multi-user.targetSave that as /etc/systemd/system/hermes.service, then sudo systemctl daemon-reload, sudo systemctl enable --now hermes. Now both openclaw.service and hermes.service are active and managed independently.
Verify they're not stepping on each other
Three quick checks tell you the coexistence works.
Run sudo ss -tlnp | grep -E '(7000|9119)' (substitute your OpenClaw port for 7000). You should see two distinct processes bound to two distinct ports. If both list hermes as the process or both list openclaw, your config is wrong somewhere.
Run sudo systemctl status openclaw hermes. Both should be active (running). If one is restarting in a loop, check its logs with journalctl -u <name> -n 50; it's almost always either a port conflict or an env file that's looking at the wrong location.
Send a test message to each bot from Telegram. The OpenClaw bot should answer in OpenClaw's voice (whatever persona you have set). The Hermes bot should answer in Hermes's voice. If both bots reply to the same message, you've configured both gateways against the same token; fix that first.
Resource sizing for running both
Two agents on the same box need a bit more breathing room than one. The numbers I've seen on real deployments:
RAM is the binding constraint. A single Hermes install with the gateway and a couple of skills loaded sits around 350 to 500 MB resident. OpenClaw is similar. Two agents idle eat about 1 GB of RAM together. Add the Python interpreters, the Node processes for tooling, the SQLite caches and the messaging client libraries; you want at least 2 GB of RAM available before you boot either, so 4 GB total on the VPS is comfortable.
CPU is rarely the bottleneck unless you're doing a lot of parallel browser automation. Most agentic work is IO-bound on the LLM call. A 1 vCPU box can host both, but a 2 vCPU box gives you enough headroom that one agent doing something busy doesn't slow down the other.
Disk depends on how much memory and history each agent accumulates. The state.db SQLite file under each agent's data dir grows roughly linearly with conversation volume, but at a slow rate. After six weeks of running both with a few hundred turns of conversation each, my ~/.hermes/state.db is 28 MB and ~/.openclaw/sessions/ is 31 MB. You won't run out of disk.
Network is the easiest. Each agent's outbound traffic is dominated by LLM API calls, which are tiny (a few KB per request). Inbound is the messaging gateway, which is also tiny. If you're on a LumaDock plan with unmetered bandwidth, you'll never notice the bandwidth difference between one agent and two.
Sharing some things on purpose
Not everything needs to be split. Three things you can usefully share between OpenClaw and Hermes if you want.
API keys for paid providers. If you have an OpenRouter key with a credit balance, both agents can read the same OPENROUTER_API_KEY from environment. Just be aware they share rate limits. The OpenClaw secrets guide covers patterns that avoid duplicating keys across both .env files.
The browser profile if you use Chrome-based automation. Two profile dirs is the safer default, but if you only run one agent at a time doing browser work and you want them to share a logged-in session, point both at the same BROWSER_PROFILE_DIR. Just don't run them concurrently against it.
The systemd journal. Both agents log to journald by default, which means journalctl -u openclaw -u hermes -f shows you a unified live tail. Useful when you're trying to spot which agent did what.
When to stop running both
The whole point of side-by-side is the trial period, not the long term. After two to four weeks, you'll have made a real decision about which agent fits your work. Pick one, decommission the other.
If you're keeping Hermes, archive your OpenClaw data and disable the unit. tar -czf openclaw-final-snapshot-$(date +%Y%m%d).tar.gz ~/.openclaw && sudo systemctl disable --now openclaw closes the loop. The OpenClaw binaries will keep working if you ever need them, but the agent will no longer start automatically.
If you're keeping OpenClaw, do the same in reverse. tar -czf hermes-trial-snapshot-$(date +%Y%m%d).tar.gz ~/.hermes && sudo systemctl disable --now hermes. The Hermes install stays on disk in case you want to come back.
If you're really going to keep both indefinitely (this happens more than you'd think, when one agent handles personal stuff and another handles work), the production hardening checklist is the right next read; running two agents long-term is fine, but it's worth tightening the security posture on both because two surfaces means twice the attack area.
The fresh-VPS option
If your existing OpenClaw VPS is small or messy, an alternative to coexistence is renting a second box for the Hermes trial. A fresh LumaDock Hermes Agent VPS gives you a clean Ubuntu 24.04 with the agent pre-installed. You scp your data across, run the migration on the new box. At the end of the trial you either kill the new box (if you're staying with OpenClaw) or kill the old one (if you're moving to Hermes), so a four-week trial is cheap insurance against picking wrong.
