Hermes multi-tenant hosting: profiles, routing, and isolation

Summary

• Hermes profiles give strong state separation—config, provider and bot credentials, memory, sessions, skills, cron, and state DB—but are not themselves filesystem or host security sandboxes.1
• A multiplexed gateway is the current one-host direction: one host process serves unparked profiles. profile_routes routes inbound traffic; it is not an authorization boundary and unmatched traffic can fall through to the default profile.2
• For untrusted external customers, reproduce the publicly described Cloud isolation model with a separate hardened container (at minimum) per tenant, not merely a profile in a shared multiplexer.[1]3

Key findings

Profiles separate Hermes state, not the host

• A profile has its own Hermes home and persistent agent state; HERMES_HOME scopes Hermes config, secrets, memory, sessions, skills, logs, cron and gateway state.1
• The local terminal backend still has the host user's filesystem access; terminal.cwd is only the starting directory, not a sandbox.1
• Host subprocesses use the real OS HOME by default, so CLI identity/config can be shared. terminal.home_mode: profile isolates tool HOME, but does not create an OS/container security boundary.1

One host gateway multiplexes profiles

• The current gateway guide describes one host multiplexer serving eligible, unparked profiles; this reduces supervisors, ports and PIDs.2
• All profiles share that gateway process and its outage/resource fate.2 Per-profile standalone gateways are now a temporary compatibility path or explicit boundary case—not the new default topology.2
• gateway.profile_routes routes by platform plus chat, thread, guild or sender fields.2
• Specificity is additive and all fields on a route must match.2
• A route normally applies to the default profile's bot unless bot_profile selects another receiving bot.2
• Sender routing selects a profile; it is not deny-by-default authorization.2
• A message matching no route stays on the default/active profile.2
• Keep each receiving bot's own platform allowlist restrictive; do not rely on route matching as the access-control boundary.2

Each profile must use unique bot credentials for a platform; duplicate polling credentials conflict.2 Profile-scoped config, memory, skills, provider keys and .env secrets are retained under multiplexing, but all still run on one host gateway.2

What the public Hermes Cloud page says—and omits

The Cloud page advertises always-on hosting with idle scale-to-zero, persistent agent memory across channels, and an isolated hardened container per agent.3 It does not disclose the tenant/org identity model, container hardening implementation, filesystem/network/credential boundaries, quotas, placement/failover, retention/backup guarantees, or how ingress wakes a scaled-to-zero agent.3 Treat those as unknown rather than assuming a self-hosted profile automatically reproduces Cloud's isolation.3

Recommendation for us

• Trusted internal/team agents: One profile per agent gives logical Hermes-state separation but shares the host and gateway boundary, so this is suitable only for tenants trusted to share that host.[1]2
  • Use unique credentials and restrictive platform allowlists.2
• External or untrusted tenants (recommended production baseline): As our architectural inference from the documented profile limits and Cloud's container claim, isolate each tenant in its own hardened container with a distinct OS identity, Hermes runtime, HERMES_HOME, persistent volume, credentials, bot tokens and resource limits.[1]3
  • Keep ingress authorization, secrets, filesystem mounts, provisioning, metering, pause/resume, upgrades and recovery tenant-scoped; these are design requirements, not details promised by Cloud.[1]3
  • A profile can still host multiple agents inside each tenant's isolated boundary.1
• High-sensitivity tenant workloads: Consider a dedicated VM per tenant if sharing a container host is outside the threat model; this is an added isolation recommendation, not a Hermes requirement.[1]3
• Do not equate profile_routes with tenant auth: unmatched traffic falls to the default profile and sender-based routing is not a complete authorization policy.2
  • Authenticate and authorize at ingress; retain profile-level allowlists.2

These deployment controls are architectural recommendations inferred from Hermes' documented boundaries; the Cloud page does not publish an implementation specification.[1][2]3

Relation

Pulse/research/tech/2026-09-17-opencode-hermes-solos-architecture

Sources

1 https://hermes-agent.nousresearch.com/docs/user-guide/profiles2 https://hermes-agent.nousresearch.com/docs/user-guide/multi-profile-gateways3 https://portal.nousresearch.com/cloud