Hermex: ein SwiftUI-Client für einen selbst gehosteten Hermes-Agenten
Native iPhone app for your Hermes agent
Auf einen Blick
- Was ist das?
- Hermex ist eine native iPhone-App, die einen hermes-webui-Server auf eigener Hardware fernsteuert. Die App bringt kein Backend mit, sie ist reine Steuerungsebene. Wer den Agenten nur auf dem Laptop nutzt, braucht sie nicht.
- Für wen ist es gedacht?
- Hermex passt zu Betreibern, die hermes-webui bereits auf eigener Hardware laufen haben und den Agenten vom iPhone aus steuern wollen, ohne einen fremden Relay dazwischen. Wer keinen Server betreiben will oder eine Android-App braucht, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Swift, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Agent auf eigener Hardware braucht eine Fernbedienung
hermes-webui ist ein serverseitiges Projekt: der Agent, seine Werkzeuge und die Daten liegen auf einer Maschine, die der Betreiber kontrolliert. Das ist der Punkt, an dem viele Agenten-Setups scheitern. Wer den Agenten nur am Rechner bedienen kann, an dem er läuft, verliert ihn unterwegs. Hermex setzt genau dort an. Die App ist ein Client, kein Backend und kein Relay. Nach Angaben des README läuft die Kommunikation ausschließlich zwischen iPhone und eigenem Server, ohne Analyse, ohne Tracking und ohne Dritten dazwischen. Das ist die Zielgruppe: Betreiber eines eigenen hermes-webui-Servers, die von unterwegs auf Sitzungen, Aufgaben und Skills zugreifen wollen. Nicht adressiert sind Nutzer, die einen gehosteten Dienst suchen. Das README formuliert es klar: die App bringt keinen Server mit, hostet keinen und provisioniert keinen.
Native Oberfläche statt Web-Wrapper, und was das praktisch ändert
Laut README ist Hermex in SwiftUI geschrieben, nicht als Web-Ansicht verpackt, und zielt auf iOS 18 oder neuer. Der Unterschied ist nicht kosmetisch. Eine native App kann Streaming-Antworten direkt in der Oberfläche aufbauen, Sitzungen lokal zwischenspeichern und Systemfunktionen wie Hintergrundverbindungen nutzen. Das README nennt konkret: Sitzungen bleiben offline lesbar, wenn sie zwischengespeichert wurden. Ebenso nennt es das Abbrechen eines laufenden Durchgangs mitten im Fluss, das Wechseln von Modell und Anbieter, den Wechsel von Agentenprofilen, das Anlegen von Projekten, das Bearbeiten geplanter Cron-Aufgaben, das Durchsuchen installierter Skills sowie einen Dateibrowser für das Dateisystem des Servers. Zwei Bereiche sind ausdrücklich lesend: Memory und Insights. Wer dort Schreibzugriff erwartet, wird enttäuscht. Die Aufteilung ist nachvollziehbar, denn Gedächtnis und Nutzungsstatistik sind heikle Daten, bei denen versehentliche Änderungen vom Telefon aus mehr Schaden anrichten als Nutzen bringen.
Der Datenfluss bleibt auf der Strecke, die der Betreiber baut
Architektonisch ist das Modell schlicht. Das iPhone ist Steuerungsebene, der Server ist Rechenebene. Die App spricht mit hermes-webui über HTTP, und die Verbindung muss der Betreiber selbst herstellen. Das README nennt drei Wege. Empfohlen ist HTTPS über einen Tunnel oder Reverse Proxy, etwa Cloudflare Tunnel, mit echtem TLS auf einem eigenen Hostnamen. Der zweite Weg ist Tailscale Serve: der Server bleibt passwortgeschützt und an 127.0.0.1:8787 gebunden, dann wird per tailscale serve --bg 8787 ein HTTPS-Endpunkt bereitgestellt, und das iPhone verbindet sich über die genaue https-Adresse aus tailscale serve status. Der dritte Weg ist reines lokales Testen im Simulator über http://localhost:8787. Bemerkenswert ist, was das README über die direkte Bindung an 0.0.0.0 über unverschlüsseltes HTTP sagt: sie bleibt ein manueller Notbehelf, nicht die Voreinstellung. Das ist eine bewusste Entscheidung gegen die bequeme Variante, und sie ist richtig, weil auf einem öffentlich erreichbaren Hostnamen das Passwort die einzige app-seitige Verteidigung ist.
Einrichtung in drei Schritten, mit konkreten Befehlen
Das README beziffert die Einrichtung mit etwa 15 Minuten und nennt drei Schritte. Erstens: hermes-webui auf macOS, Linux oder Windows mit WSL2 installieren und starten, Python 3.11 oder neuer vorausgesetzt, und HERMES_WEBUI_PASSWORD setzen. Zweitens: den Server vom Telefon aus erreichbar machen, über einen der oben genannten Wege. Drittens: Hermex aus dem App Store laden, Server-URL im Format https://hermes.yourdomain.com und das Passwort eintragen. Wer aus dem Quellcode baut, braucht laut README Xcode 26 oder neuer mit iOS-18-SDK und ein Gerät oder einen Simulator ab iOS 18. Der Befehl für den Build lautet xcodebuild -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17' build, die Testvariante entsprechend mit xcodebuild test. Wer den genannten Simulator nicht installiert hat, listet mit xcrun simctl list devices available die verfügbaren Geräte auf. Ein Detail, das beim Lesen der Repository-Struktur auffällt: das Xcode-Ziel heißt HermesMobile, der Anzeigename der App ist Hermex. Wer die Projektdateien durchsucht, sollte nach dem Zielnamen suchen, nicht nach dem Produktnamen.
Die Versionskopplung ist die eigentliche Bruchstelle
Das README ist an einer Stelle ungewöhnlich deutlich: die App wird gegen den in UPSTREAM_TESTED_SHA festgeschriebenen Commit von hermes-webui entwickelt und getestet. Der Upstream garantiert laut seinem eigenen README noch keine API-Stabilität und erklärt Versionsverschiebungen bis zur Fertigstellung einer stabilen Schnittstelle für nicht unterstützt. Daraus folgt direkt: neuere oder ältere Serverversionen können einzelne Funktionen brechen. Das ist keine theoretische Randnotiz, sondern die zentrale Betriebseinschränkung. Wer seinen Server regelmäßig aktualisiert, sollte nach jedem Sprung die gepinnte Commit-Angabe mit der installierten Version vergleichen. Der schnellste Funktionstest ist der Aufruf von /health, den das README selbst im Fehlerfall nennt: curl https://<your-server>/health. Antwortet der Endpunkt nicht, liegt das Problem vor der App. Ein zweiter Fall, in dem Hermex das falsche Werkzeug ist: wer den Agenten ausschließlich am selben Rechner bedient, an dem er läuft, gewinnt durch die App nichts. Ebenso wenig hilft sie ohne Bereitschaft, einen Server zu betreiben, abzusichern und erreichbar zu halten. Das README macht das ausdrücklich zur Aufgabe des Betreibers.
Was das für Wartung und Lizenz bedeutet
Hermex steht unter MIT-Lizenz, hermes-webui ebenfalls, das README bezeichnet es als Drittprojekt unter MIT. Für Anwender ist das unkompliziert: keine Copyleft-Pflichten, keine Offenlegung eigener Änderungen. Wer die App aus dem Quellcode baut und weiterverbreitet, muss die MIT-Bedingungen einhalten, also Lizenztext und Urheberrechtsvermerk beibehalten. Das ist keine Rechtsberatung, sondern nur die Angabe dessen, was das Repository nennt. Wartungsseitig gibt es zwei getrennte Kostenblöcke. Der erste ist der Server: Installation, Passwortpflege, Tunnel oder Tailscale-Route und Betrieb des Hosts liegen beim Betreiber. Der zweite ist die App. Die Release-Historie zeigt v1.4.0 vom 13. Juli 2026, v1.5.0 vom 4. August 2026 und v1.6.0 vom 6. September 2026, also einen monatlichen Rhythmus über diesen Zeitraum. Der letzte Push ins Repository datiert vom 10. September 2026. Ein solcher Takt bedeutet für Anwender, dass sich die App-Seite bewegt, während die Server-Seite durch die festgeschriebene Commit-Angabe gebremst wird. Wer die App aus dem Quellcode baut, muss diesen Takt selbst nachvollziehen.
Warum eine Web-Oberfläche im Browser die naheliegende Alternative bleibt
Die offensichtliche Alternative ist der Zugriff auf hermes-webui über den Browser des Telefons. Der Unterschied liegt nicht in den Funktionen, sondern im Verhalten. Eine Browser-Sitzung verliert ihren Zustand, sobald der Tab in den Hintergrund wandert oder das System ihn entlädt; ein laufender Durchgang muss neu aufgebaut werden. Hermex hält Streaming-Antworten in einer nativen Oberfläche und kann zwischengespeicherte Sitzungen offline lesbar halten, was der Browser ohne zusätzliche Maßnahmen nicht leistet. Dafür zahlt man mit einer harten Plattformgrenze: iOS 18 oder neuer, und ausschließlich iPhone. Wer ein Android-Gerät nutzt, bleibt beim Browser. Ein zweiter Unterschied ist die Verteilung. Der Browser braucht keine Installation und keinen App-Store, die App dagegen ein signiertes Build. Wer aus dem Quellcode baut, trägt die Signatur selbst. Umgekehrt ist die App kostenlos, ohne Abonnements und ohne In-App-Käufe, wie das README festhält. Die Wahl hängt also weniger am Funktionsumfang als daran, ob der Zustand einer laufenden Unterhaltung das Tab-Leben überdauern soll.
Redaktionelles Fazit
Hermex passt zu Betreibern, die hermes-webui bereits auf eigener Hardware laufen haben und den Agenten vom iPhone aus steuern wollen, ohne einen fremden Relay dazwischen. Wer keinen Server betreiben will oder eine Android-App braucht, ist hier falsch. Vor dem Kauf lohnt der Blick in UPSTREAM_TESTED_SHA und ein Aufruf von /health auf dem eigenen Server: stimmt die gepinnte Commit-Angabe nicht mit der installierten Version überein, ist ein Bruch an der API-Schnittstelle wahrscheinlicher als ein Fehler in der App.
Community-Notizen