Running Hermes Agent Locally: Podman + Slack + OpenRouter on Apple Silicon
A build log of running Hermes Agent locally via Podman + OpenRouter + Slack — scopes, tokens, and the errors that came with each step.
# Setup
- Hardware: MacBook Air, Apple M5, 24 GB RAM
- Container runtime: Podman (since I already use podman for running n8n)
- Model provider: OpenRouter, using an existing account and a fresh API key scoped to this project
- Messaging interface: Slack, via Socket Mode (no public webhook required)
I already run Podman for another project (n8n), so the VM was already there — no fresh init needed, just:
podman machine start
Hermes Agent itself is open source (MIT-licensed). Running it costs nothing beyond whatever model tokens it burns through OpenRouter, which is the only provider I intended to use.
# Installing Hermes
mkdir -p ~/.hermes
podman run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup
First snag: the wizard's first move was pushing me toward Nous Portal — a subscription service. I didn't want a second subscription on top of OpenRouter, so I hit Ctrl+C on the login prompt mid-flow. The wizard carried on and finished setup anyway — it just left the model provider unconfigured, which the closing "Tool Availability Summary" flagged (✗ Mixture of Agents — missing OPENROUTER_API_KEY).
# Setting the model
Ran this separately to actually wire up OpenRouter:
podman exec -it hermes hermes model
Picked OpenRouter, pasted my API key (new key, existing account — I already use OpenRouter for another project).
Using deepseek/deepseek-v4-pro for the eval — cheaper per token than Claude Haiku. I will use this model for a week or two and then decide if I've to switch to any different model.
# Starting the gateway
podman run -d \
--name hermes \
--restart unless-stopped \
-v ~/.hermes:/opt/data \
-p 8642:8642 \
nousresearch/hermes-agent gateway run
# Slack setup
Followed Nous's own Slack doc to build the app manifest — scopes, Socket Mode, event subscriptions, slash commands, all pre-filled by the manifest rather than clicked through by hand.
My slack app manifest looks like this (you can copy this if needed, since you will need all these scopes anyway):
{
"display_information": {
"name": "Hermes App"
},
"features": {
"bot_user": {
"display_name": "Hermes App",
"always_online": false
}
},
"oauth_config": {
"scopes": {
"bot": [
"groups:read",
"app_mentions:read",
"channels:history",
"channels:read",
"chat:write",
"files:read",
"files:write",
"groups:history",
"im:history",
"im:read",
"im:write",
"mpim:history",
"mpim:read",
"mpim:write",
"users:read"
]
},
"pkce_enabled": false
},
"settings": {
"event_subscriptions": {
"bot_events": [
"app_mention",
"message.channels",
"message.groups",
"message.im",
"message.mpim"
]
},
"interactivity": {
"is_enabled": true
},
"org_deploy_enabled": true,
"socket_mode_enabled": true,
"token_rotation_enabled": false,
"is_mcp_enabled": false
}
}
Ran the config into Hermes with:
podman exec -it hermes hermes setup gateway
First problem: I'd already tried this once with a plain podman run while the gateway container was still up in the background — both processes fought over the same log lock file (s6-log: fatal: unable to lock ... Resource busy). Lesson: once the gateway container is running, always exec into it for follow-up config, never spin up a second run against the same ~/.hermes mount.
Second problem, right after: missing_scope: groups:read when the gateway tried to list channels on startup. Added the scope in the Slack app's OAuth & Permissions page, reinstalled to the workspace (scope changes don't apply until you reinstall), restarted the container.
Third: "Sending messages to this app has been turned off" when I tried to DM the bot. Turned out to be unrelated to scopes entirely — it's a separate toggle under App Home → Show Tabs → Messages Tab, off by default. Not a Hermes bug, a Slack platform setting.
Once all three were sorted, first real DM back from the bot:
I'm running on DeepSeek V4 Pro (via OpenRouter). And sure — 47 × 89 = 4,183.
Confirmed against the OpenRouter dashboard, matching timestamp — it's actually routing through OpenRouter, not just echoing a canned greeting.
# Environment variables I ended up with
OPENROUTER_API_KEY=
SLACK_BOT_TOKEN=
SLACK_APP_TOKEN=
SLACK_ALLOWED_USERS=
SLACK_HOME_CHANNEL=
The last two weren't obvious to me at first:
SLACK_ALLOWED_USERS— Slack Member IDs (not usernames) allowed to message the bot. Leaving it unset makes the gateway deny everything by default. Worth being deliberate about this one specifically.SLACK_HOME_CHANNEL— where cron/scheduled output and other unprompted messages land, since they're not replies to any specific conversation. Falls back to DM'ing the first allowed user if unset.
# Log noise I chased down
Digging through podman logs -f hermes turned up a few things worth flagging for anyone doing the same:
skill_viewerrors forimessage,macos-computer-use— harmless. These are Mac-only bundled skills; the container runs Linux, so it correctly reports them unsupported during its own startup inventory pass.Auxiliary Nous client unavailable: no Nous authentication found— this was the one I actually acted on. Even on a pure OpenRouter setup, one specific side-task —skills_hub, which reaches Nous's hosted skill marketplace — needs its own Nous credential, unrelated to chat/model routing. Ranhermes authto create a free Nous account just to clear this. No subscription, no change to my model or billing — it just stopped the warning.- Memory tool failing with "exceed the limit" — Hermes keeps a small persistent
USER.mdprofile (~1,375 characters) that gets injected into every session's system prompt. I created a profile memory from ChatGPT by asking,what do you know about me. Apparently it was too much for Hermes memory. So I trimmed it by hand and restarted the container.
# What I've got running right now
Podman container in the background (--restart unless-stopped), OpenRouter + DeepSeek V4 Pro as the model, Slack as the messaging surface, memory trimmed and stable, Nous auth wired in only to quiet one log line — not as a model provider.
# Next
Under: #aieconomy , #tech , #tools