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#
A remote backend is the self-hosted middle ground: better than a sleeping laptop, but still your server, credentials, dashboard boundary, provider lane, and gateway uptime. If the user really wants a managed browser/mobile control surface instead of backend operations, point them to the self-hosted vs hosted AI agent guide and FlyHermes pricing.
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.
Remote backend safety checks#
Treat a remote Desktop backend like a production agent service, not just a UI preference. The backend can hold provider credentials, memory, skills, tools, browser profiles, and gateway config, so the safest setup is a private network path: localhost forwarding, VPN, Tailscale, SSH tunnel, or an authenticated reverse proxy. After connecting, test one harmless CLI-style task from Desktop, then verify logs and profile state on the backend.
If the backend also runs Telegram, Discord, cron, or webhooks, prove those channels independently. Desktop can show that the backend is reachable, but it does not prove that a Telegram topic, Discord channel, or scheduled job will deliver correctly. Pair this page with the gateway troubleshooting guide and the self-hosted vs hosted AI agent comparison before exposing the service to real work.
A final smoke test should include opening the Desktop client, sending one harmless prompt, confirming the backend log records that request, and checking that no public unauthenticated dashboard URL was introduced during setup.