Multi-Profile Gateways on One Machine

Hermes can operate several profiles as independent messaging agents on one host. Each profile keeps its own platform credentials, model setup, sessions, memory, skills, and gateway service.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/multi-profile-gateways

Choose the process model

The default pattern is one managed gateway process per profile. It provides independent restarts, separate crash domains, and clear log ownership. Install and start each profile's gateway through that profile's CLI alias or the -p selector.

For a host with many profiles, the default profile can optionally multiplex them through one inbound gateway. Multiplexing reduces process overhead but creates one shared crash domain. Secondary profile gateways must not run separately while the multiplexer owns their adapters.

Operations checklist

Give every profile unique platform credentials and delivery targets.
Verify the profile before installing its managed service.
Keep ports unique for per-profile local APIs.
Choose process-per-profile or multiplexing explicitly.
Inspect status and logs for every enabled profile.
Prevent unintended host sleep for always-on gateway machines.
Test restart behavior after login, reboot, and a controlled crash.
Document which profile owns each channel and automation.

Isolation boundaries

Profiles isolate Hermes state and configuration, but they are not operating-system sandboxes. A profile with terminal or file tools can still reach host resources allowed to that user account. Use tool selection, filesystem permissions, and service accounts when stronger boundaries are required.

In multiplexed mode, each routed turn still resolves the destination profile's configuration, skills, memory, personality, and provider credentials. Do not copy credentials into the default profile merely to make routing work.

Pitfalls

Starting two gateways against the same platform bot identity.
Enabling multiplexing while leaving secondary services running.
Assuming profiles prevent host-level file access.
Reading only the default gateway log during a named-profile failure.
Letting the host sleep and misdiagnosing lost connectivity as an agent bug.
Restarting every profile when only one service is unhealthy.

Verification steps

List profiles and record the owner of each channel.
Check gateway status for every profile.
Send one harmless message to each configured platform identity.
Confirm the reply lands in the matching profile session store.
Restart one process and verify the intended isolation behavior.
If multiplexing is enabled, confirm secondary gateway start attempts are rejected.
Reboot or relogin during a maintenance window and verify managed services recover.