Desktop & Fleet — หนึ่ง backend ทุกเครื่องในองค์กรDesktop & Fleet — One Backend, Every Laptop in the Organization

Picture it. Your team has twenty people, each with their own laptop, and all of them want an AI agent that belongs to the team rather than to any one person — the same context, the same skills, the same security rules. So how many times do you install Hermes? Twenty, or once?

The first seven posts in this series answered almost everything from the terminal's point of view. #1 Hermes 101 set the mental model — CLI + gateway daemon + session plane. #2 Agent Teams opened the multi-agent layers: delegation, Kanban, Bot Mode. #4 Security walked every defensive layer and stated flatly that Hermes has no native SSO/RBAC. #7 Production made a single box run 24/7, boringly. What was still missing was the view from the person sitting at the machine — and that is exactly where the Hermes community has been loudest for three months.

So this closing post is about Hermes Desktop as the organization's point of contact: a native app that attaches to one shared backend from every laptop, signs in through your own identity provider, ships one profile per role that is distributed and updated with git, respects values IT has pinned on the Linux backend that users cannot override (the laptops themselves cannot be pinned yet), and carries a button that updates the whole fleet. It also carries a list of limits I will not soften, because some of them — the RBAC that does not exist, the secrets that leak across profiles — are things a CTO must know before signing. And along the way I will sharpen my own "no SSO" line from #4: self-hosted OIDC is real, Portal org claims are real, tiered RBAC is not.

Why "fleet" is the question the community is actually asking

I prefer to start from data rather than mood. In the NousResearch/hermes-agent repository — which has GitHub Discussions disabled, so the community talks through issues and Discord — the most-reacted issue of all time is not about models and not about memory. It is #38602 "Desktop Client-Only Installation": 68 reactions, opened 4 June 2026, now closed. Behind it sits #36970, first-class remote-client onboarding for existing Hermes instances (31 reactions), and the same request keeps returning — #50643 for a GUI-only install (still open) and #85422, complaining that the official macOS installer still forces a local agent bootstrap when the user only wants to connect to a gateway that already exists (open since 13 August 2026).

Read together, the message is unambiguous: people do not want a twenty-first agent. They want a twenty-first window onto the agent they already have.

The other side of that coin is the most-commented human-filed issues since 1 July 2026 — almost all of them Desktop regressions: #83683, a restart reaps the live gateway and never relaunches it (33 comments); #63047, completely unresponsive on the macOS 27 beta (28); #89675, no sessions load for any profile after an update (21); #73082, renderer and GPU processes at 100% CPU while idle (18); and #93888, the Desktop sending a local runtime ID to a remote gateway and failing to restore stored sessions (17 comments, still open). That is the signature of a product people use hard enough to get hurt by, not a demo.

Late August was not quiet either: #96282, a Desktop boot timeout (P1, opened and closed on the same day, 27 August 2026); #95189, the gateway exiting every ~2 minutes on WSL2 and driving the renderer to OOM (open, P2); and #95028, "[Architecture] Hermes Authority Execution Layer — the twelve issues are one defect" (open, needs-decision) — the backdrop to the remote-auth churn that resurfaces later in this post.

A short timeline, to show how young all of this is. Nous announced Hermes Desktop as a public preview on its official X account on 2 June 2026 (that X post is the only source for the date, and I could not re-fetch it) — "First demoed in Jensen's GTC keynote, it's now in public preview." Third-party coverage calls that build v0.15.2, but I have to be precise: there is no GitHub release with that tag. The release list jumps from v2026.5.29 to v2026.6.5, whose notes count "874 commits since v0.15.2". Then v0.16.0 "The Surface Release" (tag 2026.6.5, published 6 June) folded in roughly a hundred desktop PRs; v0.17.0 (19 June) declared "The desktop is now a serious daily driver, not a preview."; and v0.21.0 "Pantheon" (31 August 2026) is the version the product page shows today.

💡 Repository scale on the day I write this (1 September 2026), via the search API: 25,442 open PRs and 12,961 open issues, with 6,875 issues opened in August alone. I deliberately do not quote GitHub's combined open_issues_count, because it folds PRs into the number.

Anatomy of Hermes Desktop

The official docs define the Desktop in one sentence worth memorising: "a native app built around the same agent you get from the CLI and the gateway" — same config, same API keys, same sessions. Architecturally it is an Electron shell whose React renderer talks to a headless hermes serve process over the tui_gateway API, JSON-RPC on a WebSocket. If you remember the three boxes from #1 — CLI, gateway daemon, session plane — the Desktop is a fourth box plugged into the same session plane, not a new agent.

# launch the Desktop from a terminal (alias: hermes gui)
hermes desktop

# what the Desktop runs underneath — the headless backend the renderer attaches to
hermes serve

# the agent's home — the same directory the CLI uses
#   macOS / Linux : ~/.hermes
#   Windows       : %LOCALAPPDATA%\hermes

One distinction matters: hermes serve is not the API server on port 8642 from #5 Integrations. That one is how you put Hermes behind other applications; hermes serve is the Desktop's own backend. I have seen several articles swap the two and send their readers down the wrong path.

On platforms, read the whole official matrix, because the product page speaks broadly — macOS 12 or later, Windows 10/11, Linux — while the platform-support page is more specific:

Two lines trip people up. Intel Macs are unsupported — an organization with pre-Apple-Silicon MacBooks still in circulation needs to count them before planning. And pip installs are unsupported too, even though v0.14.0 once announced a PyPI package (the latest PyPI release is stuck at 0.19.0 while GitHub is at v0.21.0). Keep pip off your organization's install list.

Native Windows is good news for IT: the PowerShell one-liner installs into %LOCALAPPDATA%\hermes without admin rights, provisioning Python 3.11 via uv, Node 26, a portable Git, ffmpeg and ripgrep on its own. The GUI installer and the CLI share one install directory, and the single documented limitation is the embedded terminal pane on the dashboard's /chat page, which needs a POSIX PTY.

# Windows (PowerShell) — no admin rights required
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

# Linux / macOS / WSL2
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# the Electron runtime the Desktop pulls down is roughly 114 MB

And my favourite line on the product page: "No account is needed to run the base app." The Desktop is MIT-licensed and free to download; signing in with Nous Portal is an option that opens the door to Hermes Cloud and Portal-routed models, not the front door itself.

Twenty laptops, one hardened backend

The heart of this post is Settings → Gateways, which since v0.20.2 (tag v2026.8.16) has been a multi-gateway Connections registry. The docs state the goal directly: "Register every Hermes backend you own — the local runtime, remote gateways on your LAN or VPS, SSH hosts, and Hermes Cloud instances — in one desktop app." There are four connection types:

The sentence that reframes the whole security conversation sits in the app's README: remote mode "treats the gateway host as the execution boundary: agent tools, terminal commands, and file operations run against the remote Hermes host." In the topology I am proposing — twenty laptops attached to a single hermes serve on a box hardened the way #7 describes — every shell command runs on that box, not on the laptop. The files the agent edits live there; the credentials it uses live there. The laptop is a screen.

Inside the registry the hierarchy is gateway → profile → sessions. If two gateways carry a profile with the same name, the Desktop shows them as @name-device to keep them apart. One connection is always Primary, and past thirteen profiles the strip condenses — v0.20.6 calls it the fleet profile rail. None of this landed in one release: the tracking issue #94724, "Desktop persistent multi-gateway connections — CAMPAIGN COMPLETE (29 PRs)", closed on 27 August 2026 with twenty-nine PRs behind the registry you see today.

On tokens the docs are detailed enough for a security team to read: each connection's token is stored as an owner-only (0600) file in the app's user-data directory, held by the Electron main process — "the renderer and plugins never see token bytes" — with opt-in OS-keychain encryption since v0.20.6. I am underlining "plugins never see" here because I will come back to it under managed scope.

# confirm the target backend's auth gate is really on before you hand the URL to the team
curl -s https://hermes.example.internal:9119/api/status | jq '.auth_required, .auth_providers'

# if the Desktop cannot connect — the WebSocket close code names the failing layer
#   4401 = not authenticated        4403 = authenticated but not authorized

The one thing the registry does not automate is crossing a trust boundary: "Direct bot mentions and delegation remain gateway-local by default. Crossing a backend boundary changes filesystem, credentials, tools, and trust context." If you want a bot on host A talking to a bot on host B, you configure hermes peer deliberately (the peer commands are in #2 Agent Teams; I will not repeat them).

Signing in: fail-closed auth, OIDC and the audit log

This is where I correct myself. The line "Hermes has no native SSO/RBAC" from #4 was half right. The wrong half is SSO: for a self-hosted dashboard or remote gateway, Hermes has a more serious enterprise sign-in story than I gave it credit for. The half that still stands is RBAC, which the last section covers.

Start from the principle. The dashboard binds to 127.0.0.1:9119 by default, and when you bind to a non-loopback address with no provider configured, the docs describe two behaviours. From a real terminal, Hermes "doesn't just fail — it offers to set one up on the spot" — pick username & password or OAuth right there. "Non-interactive callers — Docker/s6, CI, piped runs — skip the prompt and hit the fail-closed error." A fleet backend always runs as a service, so for it this is genuinely fail-closed: an unattended deploy never starts without auth. Three providers ship (in the source tree under plugins/dashboard_auth/: basic, nous, self_hosted, plus drain):

# option 1 — username/password: behind a VPN, nowhere else
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=ops
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=<long-random>
HERMES_DASHBOARD_BASIC_AUTH_SECRET=<session-signing-secret>

# option 2 — Nous Portal OAuth: register this install with your Portal account
hermes dashboard register
# → writes HERMES_DASHBOARD_OAUTH_CLIENT_ID into ~/.hermes/.env for you
# or open /local-dashboards in the Portal to name, manage and revoke self-hosted dashboards

# option 3 — your organization's own OIDC (Keycloak shown)
# config.yaml
dashboard:
  oauth:
    self_hosted:
      issuer: https://sso.example.ac.th/realms/staff
      client_id: hermes-desktop

# or via the environment
HERMES_DASHBOARD_OIDC_ISSUER=https://sso.example.ac.th/realms/staff
HERMES_DASHBOARD_OIDC_CLIENT_ID=hermes-desktop

The Desktop side matches this with Native Sign-In per RFC 8252: the app opens the system browser with PKCE and stores the returned tokens as owner-only files, optionally encrypted with the OS keychain — "No embedded webview, no browser session cookies." The embedded webview survives only as a legacy fallback for older gateways. After sign-in the Desktop will "sign in once and reuse the resulting session for the WebSocket via a single-use ticket", and a DNS-rebinding guard requires the Host header to match what you configured.

The piece that gives me enough confidence to take this to internal audit is the audit log: "Every login start, success, failure, and session-verify failure is written as a JSON line to $HERMES_HOME/logs/dashboard-auth.log", with access_token, refresh_token, code, code_verifier, state and the Authorization header redacted before the write.

# the latest login events — one JSON object per line
tail -n 20 $HERMES_HOME/logs/dashboard-auth.log

# ship straight into the organization's SIEM — it is already JSON lines
tail -F $HERMES_HOME/logs/dashboard-auth.log | your-log-shipper

The boundary needs stating plainly: all of that OIDC applies to the dashboard and remote gateway you host yourself, not to Nous Portal accounts. For the Portal, the documented organization mechanics are the organization picker at sign-in, org_id/org_role claims in the token, a membership re-check on every call, and the /local-dashboards page — nothing more. I could find no SSO/SAML documentation for Portal organizations as of writing (the /manage-subscription, /api-docs, /help and /local-dashboards pages returned HTTP 429 on every fetch I tried).

One agent per role: profiles and distributions

Once every laptop attaches to the same backend, the next question is "does everyone have to talk to the same agent?" Hermes's answer is the profile. #2 Agent Teams already covers the mechanics — profiles, multiplexing, Bot Mode and hermes peer (its sections 6 and 8) — and I will not repeat them; today I want to treat the profile as the organization's operating model: one profile per role.

The definition is crisp: "A profile is a separate Hermes home directory" at ~/.hermes/profiles/<name>, with its own config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs and state DB.

# one profile per role — --description feeds Kanban's routing
hermes profile create research --description "Research: literature review, paper summaries, proposal drafts"
hermes profile create finance  --description "Finance: receipts, project budgets, reconciliation" --clone

# --clone copies config/.env/SOUL/skills — never sessions or memory
# alternatives: --clone-all | --clone-from <profile> | --no-skills | --portal

# each profile gets its own shell alias
research            # same as hermes -p research
finance

Two lines from the docs the team must know by heart: "Profiles do not sandbox the agent" — they separate state, not OS-level permission — and "Never point two agent processes at the same profile", because the state DB was not designed for concurrent writers.

One gateway process per profile

Hermes's default is one process per profile — a LaunchAgent or systemd unit each, with a token lock that stops a second gateway from reusing a token (#2, section 8, has the details) — and multiplexing several profiles into one process is opt-in through gateway.multiplex_profiles. The only thing I add from the organization's side: keep the default. The last section explains why.

Bot Mode: a bot is a profile — and group rooms are still Desktop-bound

What an organization needs from Bot Mode (bundled with the Desktop since v0.20.3, official in v0.21.0 — the message_agent, group-chat and peer mechanics are in #2, section 6) comes down to three points. "a Bot is a Hermes profile", so everything in this section applies to bots unchanged. The team roster — "names and roles from each profile's title/description" — is injected into every Bot Chat's system prompt, so write each --description in the language you want the other bots to read. And every bot shares one OAuth/token pool with the main profile by default, so the bill lands on one account.

The limit that shrinks any "fleet of bots" framing: today a group room's rounds are driven by the Desktop renderer, not by a gateway. Room history and membership are mirrored to the gateways ("Rooms follow your gateways, not one Desktop"), but the round driver lives in the app. Issue #95163, "Opt-in backend-hosted group rooms" (opened 26 August 2026, P3, needs-decision), says so itself — "Rooms stall when the driving client goes away" — and #97681, "Bot Group Chats should keep working after Desktop closes" (opened 29 August 2026, P2, open), reports gateway-owned authority "now on main" with parity work remaining. A bot that must work while nobody has the Desktop open belongs on a profile cron job or on gateway-to-gateway hermes peer per #2, not in a group room.

Profile distributions: an agent versioned with git

This is the piece that turns "one agent per role" into something you can actually hand out. The docs define it — "A profile distribution packages a complete Hermes agent — personality, skills, cron jobs, MCP connections, config — as a git repository" — and draw a clean ownership line:

• Distribution-owned (replaced on update): SOUL.md, config.yaml, mcp.json, skills/, cron/, distribution.yaml
• User-owned (never touched): memories/, sessions/, state.db*, auth.json, .env, logs/, workspace/, plans/, home/, *_cache/, local/

# install a role agent from an internal repository
hermes profile install github.com/your-org/hermes-research-agent

# when the central team merges a new version, every machine pulls only what the distribution owns
hermes profile update
hermes profile update --force-config   # overwrite a config.yaml the user edited

# tarball export (careful: an export CAN include memories and sessions)
hermes profile export

Three cautions straight from the docs: distributions are unsigned by default; cron jobs that ship in a distribution are not auto-scheduled (you enable them yourself — good); and "SOULs and skills are active immediately, so vet distributions from unknown sources." For an organization, I would put the distribution repo under branch protection and PR review like any other piece of infrastructure code. The distribution-owned skills/ directory is also the practical answer to the "sharing" question from #6 Skills.

On memory: a distribution never touches memories/, and each profile carries its own MEMORY.md (2,200-character cap) and USER.md (1,375) as snapshots frozen at session start — the details are in #3 Memory. SOUL.md is loaded only from $HERMES_HOME/SOUL.md, scanned for prompt-injection patterns, and injected verbatim as the first slot of the system prompt (the repo's default is a single 546-character paragraph).

If you want one agent to speak differently per room without minting a new profile, channel_overrides in gateway-config.yaml does that:

# gateway-config.yaml — per-room override: model / provider / system_prompt
platforms:
  slack:
    channel_overrides:
      "C0FINANCE01":
        model: <model-id>
        system_prompt: "Answer only on project finance; cite the document number every time."
# this system_prompt replaces the global gateway prompt for that channel only,
# and it is ephemeral — injected per turn, never stored in history

(PR #56967 merged on 2 July 2026, but the shipping release is unpinned in the docs; the request for per-channel personality, #21637, was closed as not planned — so personality stays bound to the profile, not the room.) And when your organization arrives from OpenClaw via OpenClaw Migration, profiles plus distributions are the destination topology that the OpenClaw-era multi-agent pattern never had.

What IT can pin today (Linux hosts) and cannot (the laptops): managed scope

The classic problem with an agent on a staff laptop is that its config lives in the user's home directory — anyone can change it. Hermes answers with managed scope: root-owned /etc/hermes/config.yaml and /etc/hermes/.env, which the docs say "win over the user's ~/.hermes/config.yaml, ~/.hermes/.env, and even the shell environment — for exactly the keys it pins." The stated intent is verbatim: "for fleet/org deployments where IT needs to pin… the model provider, a shared API base URL, or security.redact_secrets: true."

# /etc/hermes/config.yaml  (root:root 0644) — pin only the keys the organization must control
model:
  provider: custom
  base_url: https://llm-gateway.example.ac.th/v1   # every machine egresses here, nowhere else
security:
  redact_secrets: true
approvals:
  mode: manual

# /etc/hermes/.env  (root:root 0644 — world-readable by design)
#   shared, non-sensitive values only — e.g. an org API base URL, feature defaults
#   an API key does NOT belong here: every local user can read this file (see the limits below)

# relocatable via HERMES_MANAGED_DIR — but that variable must itself be admin-fixed,
# otherwise a user can point it anywhere

Keys you do not pin remain the user's — and that is the elegance of it: IT owns the provider, the endpoint and the redaction policy, while users still shape their own SOUL.md, skills and profiles.

Read the managed-scope page to the end, though, because v1 carries limits the docs state themselves — and they change what this section means for a laptop fleet. (1) "Enforcement is filesystem permissions only": if a user can write the managed directory, or runs Hermes as root, managed scope is advisory. (2) "The managed .env is world-readable (0644), so any local user can read secrets pushed through it" — the docs steer it toward shared, non-sensitive values rather than high-sensitivity secrets. (3) "The agent's own tools are not hard-blocked from a managed env value": a pinned variable is applied at startup, but the agent can set a different one inside its own subprocess shell. And (4) what is explicitly "out of scope for v1": native managed locations on macOS and Windows ("v1 is Linux/POSIX-first"), layered drop-in directories (managed.d/), signed managed files, and remote/MDM delivery.

Lay point (4) over the platform table above. The Tier-1 desktops are Apple Silicon and Windows — neither has a managed scope. So what IT can pin today is Linux hosts and containers: the one backend twenty laptops attach to, which in this post's topology is exactly where the execution boundary sits. The laptops themselves, running a Local connection, cannot be pinned at all until a later version — and MDM delivery sits only on the "may come later" list.

The guide "Running Hermes on a Personal or Work Machine" lays out defaults I wish every CTO would read before worrying: approvals.mode: smart (an auxiliary LLM risk-rates commands), an approval timeout of 300 seconds that fails closed, an always-on hardline blocklist with "no override flag", write guards on ~/.ssh ~/.aws ~/.kube /etc/sudoers ~/.netrc auth.json .env, security.redact_secrets on, and "Hermes Agent does not collect telemetry." Its extra recommendations for a work machine:

# ~/.hermes/config.yaml on a staff machine (or, on a Linux host, pinned through /etc/hermes)
approvals:
  mode: manual                 # a human approves every risky command
checkpoints:
  enabled: true                # shadow-git so /rollback works

# fence the agent's writes
HERMES_WRITE_SAFE_ROOT=/Users/staff/work
# and prefer a Docker or SSH backend over local wherever you can

The guide's declared threat model is "an honest-but-wrong agent", not a malicious process — for the latter, go back to #4, every line of which still applies.

Governing Desktop plugins

The Desktop has a plugin system of its own (the Plugin SDK from v0.20.0) that has nothing to do with the agent's Python plugins — the docs say the two share "no code, no APIs, and no delivery mechanism." A plugin is a single ESM file at $HERMES_HOME/desktop-plugins/<id>/plugin.js, and the sentence IT should read twice is "A loaded plugin is evaluated as ESM in the renderer realm with full app authority" — the full authority of the app, minus the token bytes that stay in the main process, as noted above.

# plugins are distributed through a deep link that requires confirmation before install
hermes://plugin/install?repo=your-org/hermes-desktop-theme&enable=1

# my policy: allowlist internal repositories only
# and disable the home-directory scan behind the Projects sidebar on machines holding sensitive data
repo_scan_enabled: false

Three recent features bear directly on governance. v0.20.6 added consent-gated real-profile browsing — the agent may use the user's real Chromium profile only with consent (Windows gets a close-with-approval flow) — and from v0.21.0 the in-app browser "stopped being a window the agent could only look at: Hermes now navigates, clicks, and reads it directly." The Send diagnostics button "uploads a redacted debug bundle to Nous-internal storage" — opt-in each time, not telemetry. And on macOS, hermes desktop --setup-tcc-identity means "Permission grants survive every update" — no re-granting Accessibility or Screen Recording after each release, which for a twenty-machine fleet is the difference between a silent update and twenty helpdesk tickets.

Updating a fleet without breaking it

#7 taught hermes update --backup on one box. A fleet makes the same task harder by a multiple — and Nous acknowledged it in writing — then closed it. The tracking issue #91277 "[Tracking] Fleet update reliability" (opened 21 August 2026, closed as completed on 27 August — six days) opened with "~30 open issues and ~15 open PRs each patch one corner of the same class", defined deployment kinds so that each gets its own update path, and landed Phases 0–2 in full: #91283 update receipts plus fleet version verification, #91321 the macOS ps-scan fix and launchd exclusion, #91378 a full launchd fleet restart, and #91439 receipt finalisation. Those receipts and that version check are what the Update all instances button below relies on today. The line that matters most for our topology: "Docker / Hermes Cloud image — NOT updatable in place — pull new image + recreate."

On the Desktop, the Update all instances button on the Gateways page "dispatches hermes update to every eligible gateway" in an order the docs spell out: "the connected backend first, then every other eligible registered gateway (Hermes Cloud entries are platform-managed and skipped), and the desktop app itself last" — backend before app, so a new renderer never talks to an old backend. SSH connections gained a managed SSH remote-update engine in v0.20.6, and v0.21.0 added "Detached update hand-off on every OS", which fixes the Windows symptom of parking on "Updating Hermes".

# on the backend (git install) — the discipline from #7 scales to the fleet
hermes update --check          # is there a new version? do nothing yet
hermes update --backup         # back up first, then update
# hermes update rebuilds once per install and syncs skills across all profiles

# on a Docker backend — there is no in-place update
docker compose pull
docker compose up -d           # state lives in the volume, so nothing is lost

# Hermes Cloud — the Desktop skips it (platform-managed)
# or drive it through the Portal MCP server: agent → update container image

# three uninstall levels — pick the one that matches what you actually want gone
hermes uninstall --gui     # remove only the Desktop app — agent and data stay
hermes uninstall           # remove the runtime — ~/.hermes stays
hermes uninstall --full    # remove everything including ~/.hermes  ← a laptop being returned

The order I use for a fleet: (1) read the release notes — August alone ran from v0.20.0 to v0.21.0; (2) update a staging backend first and let a small group use it for a day; (3) press Update all instances from one ops machine's Desktop; (4) only then let end-user Desktops auto-update — because the loudest regressions (#83683, #89675, and the boot/repair loop in #96282/#96297) all happened "after an update".

Seeing cost and usage across the fleet

What v0.21.0 added that speaks directly to a fleet is the MCP command center, with "a fleet cost/usage overlay showing schema token estimates and 30-day usage per server, and hermes:// deep links that install an MCP server with explicit confirmation" — you can see which MCP server costs how many schema tokens and how often it was called over 30 days, across the gateways you registered. Per-delegation cost surfacing puts a price tag on each subagent that #2 taught you to delegate to.

The second instrument is the Context-usage meter, which breaks the current context's tokens down into system prompt, tool definitions, skills, memory, rules, MCP and subagent definitions — the GUI version of the hermes prompt-size that #7 recommended, and the first place I look when someone says "the agent got slower".

On billing, v0.19.0 "Quicksilver" (20 July 2026) added /subscription and /topup to the TUI/CLI with a matching billing tab in the Desktop, so a user can top up Portal credits without leaving the app (the two commands are not yet in the user guide's slash-command list; I am citing the release notes). The same v0.19.0 added Bitwarden and 1Password as secret sources — the answer to the "secrets never sit naked in .env" item that #7 put on the checklist.

Managing Hermes Cloud from the CLI over MCP

For organizations with some agents on Hermes Cloud (still a preview; the terms are a $10 minimum in credits or an active subscription, scale-to-zero when idle, and channels Telegram, Discord, Slack, Email and CLI — a subset of the platforms #5 walked through), the Desktop has auto-discovered instances through the Portal account since 10 July 2026. Accounts spanning several organizations meet an organization picker (internally an HTTP 409 org_selection_required), and Nous summarised the value in an X post on 14 August as "an agent that keeps working after you close the laptop." The ops side is reachable from the terminal through the Portal's official MCP server:

# add the Portal as an MCP server (OAuth + PKCE — one browser round-trip)
hermes mcp add --url https://portal.nousresearch.com/mcp --auth oauth hermes-cloud
hermes mcp test hermes-cloud

# then, inside a session:
#   agents  (read-only) — list, status, estimate costs
#   agent   (mutating)  — start / stop / restart / create / destroy
#                          update env vars / update container image
# tokens live under ~/.hermes/mcp-tokens/ and "membership is re-checked on each call"

What I will not write, because no public document supports it: server sizes, prices, per-tier rate limits, and where the servers are. The /cloud page carries the FAQ question "Where are the servers located?" but no answer appeared in the content I fetched. For a Thai organization that must answer to the PDPA, that alone is reason enough to keep the backend self-hosted until the documentation exists.

Honest limits and an org checklist

I promised at the top not to soften anything. Here is the list as of 1 September 2026.

1. No tiered RBAC. Issue #527, "Gateway Permission Tiers — RBAC (Owner/Admin/User/Guest)", has been open since 6 March 2026 (22 reactions, labelled needs-decision). Authorization today is binary, evaluated in order: per-platform allow-all → DM pairing → per-platform allowlist → global allowlist → global allow-all → default deny. The FAQ confirms multi-user access exists only through allowlists and DM pairing — whoever passes the allowlist can do everything the agent can do.

2. Secrets leak across profiles under multiplexing. Issue #82936 reports that under gateway.multiplex_profiles the default profile's secrets leak into a secondary profile's terminal tool and Kanban worker subprocesses — opened 10 August 2026, labelled type/security, P2, and still open. It contradicts the multiplexing doc's claim of per-profile .env isolation. I present it as an unresolved contradiction, not a fixed bug.

3. Data isolation in group rooms is still the model's job. The bednars.me critique (12 July 2026, on the $20 Portal tier) describes the agent disclosing private context after being added to a test group, and concludes that "the model should never be responsible for deciding whether another participant may access data." It is a third-party opinion, but it is consistent with point 1 and with issue #4281 (gateway sessions on a local backend are not sandboxed), which is still open, as #4 recorded.

4. No SSO/SAML/RBAC documentation for Portal organizations. The phrase "granular access controls" from the Hermes Cloud announcement (an X post of 8 July 2026 — the only source, and one I could not re-fetch) remains just a phrase. The documented org mechanics are the org picker, org_id/org_role claims, the per-call membership re-check, and /local-dashboards. The Portal Terms of Service (updated 18 June 2026) contain no organization-account or seat mechanics at all — only non-refundable fees, account deletion within six months of termination, and arbitration in Cupertino.

5. No public status page that I could find, and Hermes Cloud still publishes no server sizes, prices or regions.

6. The egress proxy covers Docker only. iron-proxy "wires the egress proxy into the Docker backend only. Modal, Daytona, SSH, and Singularity do not receive proxy env vars or CA mounts yet." If your fleet's backend uses SSH mode, egress control has to happen at the network layer.

7. Bot Mode group rooms stop when the Desktop closes. The round driver lives in the Desktop renderer (#95163, open, P3, needs-decision; #97681, open P2 since 29 August 2026 — gateway-owned authority "now on main", but not yet at parity). A "bot team that works 24/7" therefore means per-profile cron jobs and gateway-to-gateway peers today, not a group room.

In fairness, the Hermes Atlas report "State of Hermes Agent — July 2026" (a community project unaffiliated with Nous) names scale-to-zero, managed scope, profile multiplexing and drain coordination as the quarter's "hosted/team deployment" signals. The direction is right; the set is not yet complete.

Checklist before rolling Hermes Desktop out to the organization

• ☐ Count the machines: Intel Macs, and pip/brew/AUR install paths, are unsupported
• ☐ The Desktop backend is a dedicated box, not one still serving TUI/gateway users (#40656 is open)
• ☐ The dashboard is never bound outside loopback without OIDC/OAuth — and username/password lives behind a VPN only
• ☐ dashboard-auth.log is shipped to the SIEM
• ☐ One profile per role, one gateway process per profile — multiplexing stays off (#82936)
• ☐ Every role's distribution lives in a branch-protected repo; distribution cron jobs are enabled by hand after review
• ☐ On the Linux backend: /etc/hermes pins provider, base_url and redact_secrets, HERMES_MANAGED_DIR is locked, and no secret sits in the world-readable managed .env — the Mac and Windows laptops have no managed scope yet
• ☐ Desktop plugins install from an allowlist of repos only, because a plugin has full app authority
• ☐ The update order — staging → backend → Update all instances → user Desktops — is written down as a runbook
• ☐ If Hermes Cloud is in scope: legal knows that region and retention are undocumented

My closing position for the series: Hermes Desktop as the "twenty-first window" onto a hardened backend is a topology I am ready to pilot with a small team today. What Nous built in three months — the Connections registry, OIDC, distributions, managed scope, fleet update — covers more than half of what an organization needs. The other half — RBAC, tenant isolation that does not rely on the model, and Cloud documentation that answers where the data lives — is the list I will re-check before approving it for the whole organization. The best system is still the most boring one, and a boring fleet is a fleet somebody designed to be boring from day one.