Hermex: an iPhone client for a Hermes agent you host yourself

The gap Hermex fills: a phone in front of a server you already run

A self-hosted agent is reachable from a laptop browser and awkward from anywhere else. If hermes-webui runs on a home machine or a small VPS, checking a long-running session means opening a laptop, or trusting a mobile browser with a desktop web UI. Hermex targets that specific moment. It is a native SwiftUI app for iOS 18 and later, and the README frames the split plainly: the phone is the control plane, the agent, its tools, and your data stay on your own hardware. The intended user is someone who already operates a hermes-webui instance and wants a client that talks only to that server. There is no account system to create, no relay in the middle, and the README states there is no analytics or tracking. That last point is a design constraint, not a feature list item: with no third-party relay, reachability becomes your problem, which the setup section addresses directly. Hermex is free, with no subscriptions and no in-app purchases, and it is distributed both on the App Store and as source under MIT. The repository is Swift, the Xcode target is named HermesMobile, and the app's display name is Hermex, a mismatch worth knowing before you open the project.

What the app actually exposes: chat, sessions, tasks, skills, workspace, memory

The feature set maps to surfaces that already exist on the server. Chat sends messages with model, reasoning-effort, workspace, and profile options, accepts file and image attachments, and streams responses with thinking and tool-call detail visible as they arrive. A run can be steered or stopped mid-flight, which matters for an agent that may be several tool calls into a task. Sessions can be browsed, searched, and resumed, and the README notes that cached sessions stay readable offline, so a previously loaded conversation does not vanish when the phone loses signal. Model selection covers whatever providers the server is configured for, with recents and favorites. Profiles and projects are switchable from the app. Tasks surfaces the agent's scheduled cron jobs for viewing and editing, Skills offers a searchable list of installed skills, and a workspace browser explores the server's file system. Memory and Insights are described as read-only panels for agent memory and usage analytics. Two of these deserve emphasis because they are the least common in mobile agent clients: editing cron jobs from a phone, and a file browser pointed at the server. Both are administrative surfaces rather than conversational ones, and both assume the server is the source of truth.

The data path: your server URL plus a password, nothing in between

The architecture is deliberately small. Hermex holds a server URL and a password, and talks to hermes-webui over HTTPS. There is no backend operated by the app author, which is why the README can claim the app talks only to your server. The consequence is that every reachability and transport decision belongs to you. The README's recommended path is real TLS at a hostname you own, through Cloudflare Tunnel or any reverse proxy, because real HTTPS keeps iOS App Transport Security satisfied with no exceptions. A second documented option is Tailscale Serve: keep the server password-protected and bound to 127.0.0.1:8787, inspect existing Serve or Funnel routes, then add the route only when HTTPS port 443 at the root path is free. The app then connects using the exact https URL reported by tailscale serve status. Plain HTTP bound to 0.0.0.0 is described as a manual fallback rather than the default, and localhost over HTTP is scoped to simulator testing on the same Mac. The README also states the obvious risk without softening it: on a publicly reachable hostname, the password is your only app-level defense. That is the whole security model at the application layer, and it is worth reading as a constraint rather than a footnote.

Getting it running: server first, then a URL and a password

Setup is estimated at about 15 minutes and starts on the server side, not in the app. Install and start hermes-webui on macOS, Linux, or Windows with WSL2, requiring Python 3.11 or newer, and set HERMES_WEBUI_PASSWORD. Make the server reachable using one of the documented options. Then install Hermex from the App Store, enter the server URL (the README's example is https://hermes.yourdomain.com) and the password. If connection testing fails, the README lists four things to check in order: the host machine is awake, hermes-webui is running and serving /health (curl https://<your-server>/health), the tunnel or proxy or Tailscale route is connected, and the URL and password are correct. Building from source is documented for developers only, and the README says to prefer the App Store build unless you are developing. It requires Xcode 26 or newer with the iOS 18 SDK, and an iPhone or simulator on iOS 18 or later. The command-line build is xcodebuild -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17' build, with the test variant using xcodebuild test on the same scheme and destination. If that simulator is absent, xcrun simctl list devices available enumerates what you have. Dependencies resolve through Swift Package Manager, and local validation defaults for XcodeBuildMCP users live in .xcodebuildmcp/config.yaml, with the post-change flow in DEVELOPMENT.md.

Version skew is the real failure mode, and upstream says so

The strongest limitation is not in the app. The README states that Hermex is developed and tested against the hermes-webui commit pinned in UPSTREAM_TESTED_SHA, and that upstream does not yet guarantee API stability, with the upstream README declaring version skew unsupported pending its stable-API work. In practice this means a server newer or older than the pinned commit may break individual features, and the failure could look like a screen that loads nothing rather than a clear error. This is a client whose correctness depends on a moving target it does not control. Two smaller constraints follow from the same design. First, the app is iPhone-only: the README describes it as a native SwiftUI iPhone app, and iOS 18 is the floor, so older devices are out. Second, the read-only labelling of Memory and Insights is a boundary, not a bug; if you need to edit agent memory from the phone, this is the wrong tool for that task. The offline story is also partial. Cached sessions stay readable offline, but nothing in the material suggests new messages or task edits queue up and sync later, so treat offline mode as a reader, not a client. Finally, the README does not document a self-hosted server bundled with the app, and the app does not provision anything. If you do not already run hermes-webui, Hermex has nothing to connect to.

Where a browser or a chat-style client differs

The obvious alternative is the hermes-webui web interface itself, which the README links as a third-party, MIT-licensed open-source project. The difference is not cosmetic. A browser reaches the server from any device with a browser and no install, which is exactly what you want on a borrowed laptop, and it requires no App Store account, no iOS 18 device, and no Xcode if you build from source. What it does not give you is a native client: no App Store distribution, no cached sessions readable offline, and no iOS-level handling of attachments or streaming in a purpose-built view. Hermex trades portability for a phone-shaped interface. The other comparison worth drawing is with hosted agent apps, where the model runs on someone else's infrastructure and the mobile app is a front end to that service. Hermex inverts that: the server is yours, the data stays on your hardware, and the app is a thin client with a URL field. If your reason for wanting a mobile agent client is convenience rather than control, the hosted model asks less of you. If your reason is that the agent has access to your files and scheduled jobs, the self-hosted split is the point, and the cost is that you own the tunnel, the certificate, and the password.

Maintenance, licensing, and what the repository tells you to check

Hermex is MIT-licensed, which permits reuse and modification under the terms in the LICENSE file; that is a statement about the licence text, not legal advice for your situation. The app is free with no subscriptions or in-app purchases, and the README links a Buy Me a Coffee page, so funding is voluntary rather than a paid tier. Release cadence is visible in the repository: v1.4.0 in July 2026, v1.5.0 in August, v1.6.0 in early September, which suggests active work but says nothing about stability. The maintenance cost that matters is not the app's. It is the server's, because the app's compatibility is tied to UPSTREAM_TESTED_SHA. When you upgrade hermes-webui, you are changing the contract a pinned client was tested against, and the README's own troubleshooting list starts with the host being awake and /health responding, which is a server-side check, not an app-side one. The practical upgrade path is to note the commit in UPSTREAM_TESTED_SHA before moving your server, and to keep the App Store build current rather than building from source unless you are developing. The README also points to CONTRIBUTING.md and the issue tracker, and notes the repository is not archived, so the project is presented as maintained.

Editorial conclusion

Adopt Hermex if you already run hermes-webui on hardware you control and want to check sessions, tasks, or a streaming run from a phone without standing up a web UI. Do not adopt it if you have no server, or if you expect the app to provision, host, or secure one; the README is explicit that it is a client only. Before installing, confirm your server's commit against UPSTREAM_TESTED_SHA and that /health answers over the exact URL you plan to enter in the app.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. uzairansaruzi/hermex on GitHub