Hermes Desktop is useful when you want a native app surface while the real agent runtime lives somewhere else: a laptop, a lab machine, a VPS, or a managed backend. The important boundary is simple: Desktop is the client surface; the backend owns the agent runtime, tools, profiles, credentials, memory, and gateways.
Quick answer#
Connect Hermes Desktop to a remote backend when you want the comfort of a desktop UI but the agent should run on a different machine. Update Hermes Desktop, configure the remote backend URL in the Desktop connection settings, use local/custom endpoints when the backend exposes an OpenAI-compatible provider, then verify the active profile, provider, tools, and gateway state from the Hermes Web UI. Keep the backend private; do not expose a raw admin dashboard to the public internet.
When a remote backend makes sense#
Use a remote backend when:
- The agent must keep running after your laptop sleeps.
- You want Telegram, Discord, webhook, or cron jobs to stay online from a VPS.
- The machine with models, Docker, browser automation, or private network access is not the machine with the UI.
- A teammate needs a clearer app surface without shell access.
If you only want a managed browser/mobile experience and channel uptime, compare this with FlyHermes. Remote Desktop plus self-hosting still leaves you responsible for server operations.
What changed recently#
The latest Hermes GitHub work improved Desktop and provider setup in three practical ways:
- Local/custom endpoints can be configured without pretending they need a hosted API key.
- Local/custom endpoints are wired into model assignment, so Desktop can route to the backend you actually selected.
- Desktop update handling is safer for managed clones, reducing the chance that update stash/restore behavior clobbers source state.
That makes a Desktop-to-backend setup less brittle, especially for users combining a native UI with self-hosted models or a remote Hermes service.
Setup checklist#
- Update Hermes Desktop and the backend Hermes install.
- Confirm the backend is reachable from the Desktop machine through a private URL, VPN, SSH tunnel, or trusted reverse proxy.
- Configure the remote backend URL in Desktop.
- Configure any local/custom model endpoint on the backend, not only in the Desktop UI.
- Open the Hermes dashboard for the backend profile and confirm provider, model, tools, memory, skills, cron, and gateway state.
- Run one low-risk tool call before trusting the setup with file edits, messages, or scheduled jobs.
Security boundary#
A remote backend is powerful because it owns the tool runtime. Treat it like an admin service:
- Do not publish the dashboard directly to the internet.
- Keep provider keys on the backend, not scattered across clients.
- Use separate Hermes profiles for personal, work, and bot contexts.
- Use the gateway troubleshooting guide when a channel stops replying instead of rotating every credential at once.
Desktop vs Web UI vs FlyHermes#
- Hermes Desktop: native client surface for local or remote Hermes work.
- Self-hosted Web UI: operations dashboard for config, provider, profile, memory, skills, cron, tools, and gateway status.
- FlyHermes: hosted cloud path for browser/mobile access, connected channels, and managed uptime.
The right choice depends on whether you want to operate the backend yourself. If yes, Desktop plus a remote backend is a strong setup. If no, use the hosted path.