Die Wahl zwischen einem gehosteten und einem selbst gehosteten persönlichen Agenten ist keine Wahl zwischen „einfach“ und „privat“. Es ist eine Wahl darüber, wer welchen Teil des Systems betreibt, wohin seine Daten fließen und welche Ausfälle in die eigene Verantwortung fallen.
Diese Unterscheidung zählt bei einem persönlichen Agenten mehr als bei einer einfachen Chat-App. Ein Agent kann laufende Tasks halten, ein Modell aufrufen, im Web suchen, sich mit anderen Diensten verbinden, in einer Computerumgebung arbeiten und später mit einem Ergebnis zurückkommen. Wer die Anwendung auf die eigene Maschine holt, verschiebt einige dieser Grenzen. Nicht jede Abhängigkeit zieht dabei automatisch mit.
Comma bietet beide Wege: einen von Comma betriebenen gehosteten Dienst und ein Open-Source-Deployment, das sich mit Docker Compose betreiben lässt. Das Produkt ist in beiden Formen wiederzuerkennen, doch das Betriebsmodell und einige Fähigkeiten sind nicht identisch. Dieser Leitfaden erklärt die Abwägung, ohne Self-Hosting als Auszeichnung oder gehostete Software als Kompromiss zu behandeln, den alle meiden sollten.
Die kurze Antwort
Gehostetes Comma passt, wenn der Agent genutzt werden soll, ohne selbst zum Betreiber seiner Infrastruktur zu werden. Comma betreibt den Dienst, speichert die Daten des gehosteten Workspace, kümmert sich um Updates und Backups und stellt einen Cloud-Computer für den Workspace bereit. Das gehostete Produkt umfasst außerdem die von Comma beschriebene Meeting-Aufzeichnung. Im Gegenzug für diesen verwalteten Dienst gelten die Grenzen des Dienstes bei Konto, Tarif, Datenverarbeitung und Verfügbarkeit.
Selbst gehostetes Comma passt, wenn die Kontrolle über den Anwendungs-Stack, die Datenbanken, die Modellkonfiguration und die Deployment-Umgebung den Betriebsaufwand wert ist. Die Instanz läuft auf einer selbst verwalteten Maschine, und die Anwendungsdaten liegen in selbst betriebenen Datenbanken und Objektspeichern. Upgrades, Backups, die Konfiguration des öffentlichen Netzwerks, Kapazität, Monitoring und die Wiederherstellung nach Störungen gehören dann ebenfalls zur eigenen Verantwortung. Modellaufrufe und optionale Integrationen können trotzdem Daten an externe Anbieter senden.
Keine der beiden Optionen erspart es, Berechtigungen und verbundene Dienste zu verstehen. Die nützliche Frage ist nicht nur Wo ist Comma installiert? Sie lautet: Wer betreibt jede Komponente, und wohin gehen Informationen, wenn dieser Task ausgeführt wird?
Verantwortung vergleichen, nicht Schlagworte
Der offizielle Self-Hosting-Leitfaden macht die Aufteilung konkret:
Das ist keine Punktetabelle für Funktionen. Für die eine Person sind fünf persistente Volumes und ein Reverse Proxy eine unnötige Ablenkung. Für eine andere ist es der Hauptgrund für das Produkt, die Anwendung und ihre Datensätze auf selbst kontrollierter Infrastruktur zu halten. Die bessere Option ist die, deren Verantwortung sich tatsächlich dauerhaft tragen lässt.
Dem Datenweg folgen
„Selbst gehostet“ beschreibt, wo der Comma-Stack läuft. Es bedeutet nicht, dass jedes Byte auf dieser Maschine bleibt.
Im standardmäßigen selbst gehosteten Stack liegen Tasks, Chats und Dateien in selbst betriebenen Diensten. Das Compose-Deployment umfasst neben dem Comma-Server und den Clients PostgreSQL, Redis, ClickHouse, MinIO und ein Konfigurations-Volume. Laut dem Leitfaden von Comma sendet der Stack keine Analysedaten oder Traces an Comma. Das ist eine nützliche Grenze, aber die Analyse des Datenflusses endet dort nicht.
Ruft der Agent ein Modell auf, geht die Anfrage an den Modellanbieter, der für diese Instanz konfiguriert ist. Wird ein Exa-Schlüssel für Websuche und das Lesen von Seiten hinzugefügt, gehen die entsprechenden Anfragen an Exa. Wird die Instanz öffentlich gemacht, brauchen die Anmeldecodes einen echten Mailserver. Verbundene Apps und alle Websites, die der Agent nutzt, bleiben eigenständige Dienste mit eigener Datenverarbeitung. Auch ein Reverse Proxy, ein DNS-Anbieter, ein Hoster und ein Backup-Ziel können Teil des Betriebswegs werden, den man selbst entwirft.
Gehostetes Comma hat einen anderen Weg. Comma betreibt die Anwendung und speichert die Daten des gehosteten Workspace, während die Wege von Modellen und Integrationen von der gehosteten Konfiguration und den gewählten Diensten abhängen. Hosting nimmt die Serververwaltung ab; es nimmt nicht die Entscheidung ab, was verbunden wird und welche Informationen ein Task nutzen soll.
Bei beiden Deployments lohnt es sich, einen realistischen Workflow nachzuzeichnen, bevor eine pauschale Aussage über Datenschutz getroffen wird. Fasst ein Task ein Drive-Dokument mit einem externen Modell zusammen, stellen sich diese Fragen:
Wo werden der Task und der Verweis auf das Dokument gespeichert?
Welcher Dienst ruft die Quelle ab?
Welcher Inhalt steckt in der Anfrage an das Modell?
Welcher Anbieter erhält diese Anfrage?
Wo werden Ergebnis, Logs und Backups aufbewahrt?
Wer kann die Verbindung widerrufen oder den gespeicherten Zustand löschen?
Diese Übung zeigt mehr als das Etikett des Deployments. Self-Hosting kann direkte Kontrolle über wichtige Speicher und Konfigurationen geben, aber der vollständige Weg ist eine Eigenschaft des Workflows, den man baut.
Ein eigenes Modell ist eine Routing-Entscheidung
In der selbst gehosteten Konfiguration von Comma lassen sich Endpoint, Protokoll, Modell-ID, API-Schlüssel, Kontextbudget und Ausgabelimit des Modellanbieters festlegen. Anbieteraufrufe laufen über das eigene Konto beim Anbieter, also gehören Abrechnung und Anbieterbedingungen zu dieser Beziehung und nicht zu Comma-Guthaben.
Diese Flexibilität erlaubt mehrere Varianten. Die API eines kommerziellen Modells kann mit dem eigenen Konto genutzt werden, ein kompatibler privater Endpoint kann angesteuert oder ein selbst betriebenes Modell konfiguriert werden. Diese Optionen sollten nicht unter „lokale KI“ zusammengefasst werden. Eine selbst gehostete Comma-Instanz, die Prompts an ein Cloud-Modell sendet, hat weiterhin einen externen Datenweg zum Modell. Ein privates Modell kann diesen Weg ändern, aber nur, wenn der konfigurierte Endpoint und die umgebende Infrastruktur tatsächlich innerhalb der beabsichtigten Grenze liegen.
Zugangsdaten verlangen dieselbe Sorgfalt. Den Stack zu betreiben heißt, Modellschlüssel, generierte Secrets, Mail-Zugangsdaten und alle Tokens zu schützen, die Integrationen nutzen. Kontrolle über die Konfiguration ist gerade deshalb wertvoll, weil die Konfiguration Verantwortung trägt.
Self-Hosting heißt, ein System zu betreiben
Das öffentliche Repository bietet einen vollständigen Ausgangspunkt mit Docker Compose auf einem einzelnen Knoten. Es baut den Web-Client, den Admin-Client und den Server und startet die zugehörigen Datendienste. Der erste Start kann lokal erfolgen: Die Ports sind standardmäßig nur an Loopback gebunden, und Mailpit stellt einen lokalen Posteingang für Anmeldecodes bereit.
Dass es lokal läuft, ist kein Nachweis der Produktionsreife. Ein öffentliches Deployment braucht HTTPS hinter einem Reverse Proxy, getrennte Origins für Web-App, Admin-App und Produkt-API sowie einen echten SMTP-Dienst. Die öffentliche Registrierung ist standardmäßig aus. Zu entscheiden ist, wer die Instanz erreichen kann, wie Zertifikate und DNS verwaltet, wie Secrets gespeichert und wie Sicherheitsupdates eingespielt werden.
Auch Backups sind eine Eigenschaft des Systems, nicht die Kopie einer Datenbank. Der Leitfaden von Comma sieht vor, den Stack anzuhalten und alle fünf benannten Volumes gemeinsam zu sichern: config, postgres, objects, clickhouse und redis. Das Konfigurations-Volume enthält den Verschlüsselungsschlüssel und die Authentifizierungs-Secrets. Geht es verloren, während die anderen Volumes erhalten bleiben, bleiben womöglich Daten übrig, die sich nicht sinnvoll wiederherstellen lassen. Ein Backup-Plan ist erst vollständig, wenn eine Wiederherstellung getestet wurde.
Upgrades bringen eine weitere Pflicht mit sich. Nötig sind Wartungsfenster, genug Speicherplatz für Builds, eine Möglichkeit, ausgefallene Dienste zu erkennen, und ein zur Nutzung passender Rollback- oder Wiederherstellungsplan. Wird der Agent Teil der täglichen Arbeit, werden Verfügbarkeit der Maschine, Zustand des Speichers und Netzwerkkonfiguration zu Produktfragen, die sonst der gehostete Dienst auffangen würde.
Open Source verändert, was sich prüfen und anpassen lässt; diese Betriebsarbeit fällt dadurch nicht weg. Der Originalcode von Comma steht unter AGPL-3.0-only, und das Repository erklärt die Pflicht zur Bereitstellung des Quellcodes für veränderte Versionen, die als Dienst angeboten werden. Das ist echte Kontrolle, aber etwas anderes als ein Sicherheitsaudit, ein Supportvertrag oder eine Garantie, dass ein bestimmtes Deployment richtig konfiguriert ist.
Cloud-Computer sind auf beiden Wegen nicht dieselbe Fähigkeit
Das gehostete Produkt stellt für jeden Workspace einen Cloud-Computer bereit. So hat der Agent eine Umgebung für Arbeit, die Dateien, Werkzeuge oder browserähnliche Ausführung über einen einzelnen Modellaufruf hinaus braucht, ohne dass Nutzer diese Umgebung eigens einrichten müssen.
Stand 26. Oktober 2026 sind Gruppen-Cloud-Computer im öffentlichen Self-Host-Stack standardmäßig aus und erfordern Cloudflare-Konfiguration. Das Repository macht diese Fähigkeit nicht automatisch zu einer verfügbaren lokalen Sandbox, nur weil die Kerndienste laufen. Ist Arbeit auf einem Cloud-Computer zentral für die eigenen Tasks, gehören ihre Laufzeitumgebung, Konfiguration, Kosten, Isolation und Wartung in die Entscheidung – nicht nur der Anwendungsserver.
Das kann die praktische Antwort verändern. Wer vor allem dauerhafte Tasks, verbundene Modellaufrufe und Kontrolle über gespeicherte Anwendungsdaten braucht, nimmt die zusätzliche Einrichtung vielleicht in Kauf. Wer einen sofort nutzbaren Ausführungscomputer als Teil der Agentenerfahrung erwartet, bevorzugt womöglich gehostetes Comma, auch wenn Docker kein Problem wäre.
Meeting-Aufzeichnung hat eine eigene Laufzeitgrenze
Dieselbe Warnung gilt für Meetings. Stand 26. Oktober 2026 umfasst die gehostete Comma-Erfahrung die Meeting-Aufzeichnung, doch laut dem öffentlichen Self-Host-Repository brauchen Meetings und Agent-VMM-Hosts Laufzeitumgebungen, die das Repository nicht enthält.
Wer die Kernanwendung selbst hostet, bildet den vollständigen gehosteten Meeting-Weg daher nicht nach. Zusätzliche Infrastruktur lässt sich bauen oder integrieren, wobei die für die eigene Situation relevanten Berechtigungen, Aufzeichnungsgesetze, Speicherkonzepte und Transkriptionsanbieter zu beachten sind. Das wäre ein selbst betriebenes System, kein mitgelieferter Schalter im Standard-Compose-Stack.
Das ist als ausdrückliche Produktgrenze zu behandeln. Ist das Aufzeichnen und Verarbeiten von Gesprächen ein entscheidender Anwendungsfall, sind gehostetes und selbst gehostetes Comma heute nicht austauschbar.
Ein Verantwortungstest vor der Wahl
Die nützlichste Frage zum Self-Hosting ist nicht „Lässt sich Docker betreiben?“. Sie lautet: „Soll dieser Dienst nach dem ersten erfolgreichen Start dauerhaft in eigener Verantwortung liegen?“
Self-Hosting passt gut, wenn eine dauerhafte Maschine oder ein Server vorhanden ist, ihr Zustand geschützt und gesichert werden kann, die konfigurierten externen Anbieter verstanden sind und direkte Kontrolle genug zählt, um das Deployment zu pflegen. Besonders relevant wird es, wenn eine eigene Netzwerkgrenze, ein eigener Modell-Endpoint, ein eigener Aufbewahrungsprozess oder Anpassungen auf Quellcodeebene nötig sind.
Gehostetes Comma passt gut, wenn das Ergebnis wichtiger ist als der Server, der verwaltete Cloud-Computer oder der Meeting-Weg gebraucht wird oder die Verfügbarkeit des persönlichen Agenten nicht von den eigenen Wartungsgewohnheiten abhängen soll. Die gehostete Variante verhindert nicht, Berechtigungen sorgfältig zu setzen oder zu begrenzen, was verbunden wird. Sie überträgt lediglich den Betrieb der Infrastruktur an Comma.
Vor der Entscheidung lohnt es sich, diese Fragen schriftlich zu beantworten:
Welche Daten müssen auf selbst betriebener Infrastruktur gespeichert werden?
Welcher Modellanbieter erhält Inhalte aus Tasks, und über welches Konto?
Brauchen die wichtigsten Workflows einen Cloud-Computer oder Meeting-Aufzeichnung?
Lassen sich HTTPS, Mailzustellung, Secrets, Updates und Zugriffskontrolle verwalten?
Was umfasst das Backup, und wurde die Wiederherstellung getestet?
Wer bemerkt und behebt einen Ausfall während einer Abwesenheit?
Fällt die Wahl auf Self-Hosting wegen einer konkreten Grenze oder nur, weil das Wort sicherer klingt?
Weisen die Antworten in verschiedene Richtungen, empfiehlt sich der Start mit dem Deployment, das den wichtigsten Workflow trägt. Ein klar abgegrenzter Task und sein realer Datenweg verraten mehr als ein abstrakter Funktionsvergleich.
Fragen zu gehosteten und selbst gehosteten persönlichen Agenten
Ist selbst gehostetes Comma automatisch privater?
Nein. Es stellt den Anwendungs-Stack und seine Datenbanken unter eigene Kontrolle, und der Standard-Stack sendet keine Analysedaten oder Traces an Comma. Modellanbieter, Suche, Mail, verbundene Apps, Netzwerkdienste und Backups können trotzdem Daten empfangen oder speichern. Datenschutz hängt von der gesamten Konfiguration und dem gesamten Workflow ab.
Braucht selbst gehostetes Comma ein Comma-Konto oder ein Abonnement?
Der öffentliche Docker-Compose-Stack braucht weder ein Comma-Konto noch Stripe noch Comma-Guthaben. Die Maschine wird selbst bereitgestellt, und ein Konto bei einem Modellanbieter oder ein privates Modell wird konfiguriert. Diese Entscheidungen können eigene Infrastruktur- und Nutzungskosten haben.
Lässt sich ein eigener Modellanbieter nutzen?
Ja. Der selbst gehostete Stack bietet Einstellungen für Anbieter-Endpoint, Protokoll, Modell und Zugangsdaten. Ein selbst betriebener Anbieter ist möglich, wenn er die nötige Schnittstelle unterstützt, aber Self-Hosting von Comma macht ein Drittanbietermodell nicht von sich aus lokal.
Enthält die selbst gehostete Version einen Cloud-Computer?
Nicht als sofort nutzbare Voreinstellung. Laut dem offiziellen Leitfaden von Comma brauchen Gruppen-Cloud-Computer eine Cloudflare-Konfiguration. Hängen die Workflows von Ausführung auf einem Computer ab, gehört diese separate Einrichtung samt ihrer Betriebsgrenze in die Planung.
Enthält die selbst gehostete Version die Meeting-Aufzeichnung?
Nein. Laut dem öffentlichen Repository sind Meeting-Laufzeitumgebungen nicht enthalten. Für diesen Anwendungsfall unterscheiden sich der gehostete Dienst und der Standard-Self-Host-Stack daher.
Was muss gesichert werden?
Die fünf benannten Volumes – Konfiguration, PostgreSQL, Objekte, ClickHouse und Redis – werden bei angehaltenem Stack als ein Satz gesichert. Das Konfigurations-Volume muss erhalten bleiben, weil es die Verschlüsselungs- und Authentifizierungs-Secrets enthält. Vor einem Upgrade oder einer Wiederherstellung gilt der aktuelle Self-Hosting-Leitfaden.
Ist Open Source dasselbe wie sicher?
Nein. Verfügbarer Quellcode macht Prüfung, Anpassung und unabhängigen Betrieb möglich. Sicherheit hängt weiterhin vom Code, seinen Abhängigkeiten, der eigenen Konfiguration, der Netzwerkexposition, den Zugangsdaten, der Update-Praxis und der Reaktion im Betrieb ab.
Die Grenze wählen, die sich halten lässt
Ein gehosteter persönlicher Agent verlangt, einem Dienstbetreiber zu vertrauen und ihn zu bewerten. Ein selbst gehosteter persönlicher Agent verlangt, selbst zum Betreiber zu werden. Comma unterstützt beides, weil Kontrolle und Bequemlichkeit keine allgemeingültigen Vorlieben sind und weil die richtige Grenze von der Arbeit abhängt, die delegiert werden soll.
Für die verwaltete Variante ist gehostetes Comma der Einstieg. Wer den Stack selbst betreiben will, liest den vollständigen Self-Hosting-Leitfaden, prüft das offizielle Repository und plant die Grenzen für Modell, Netzwerk, Backups, Cloud-Computer und Meetings, bevor wichtige Tasks darauf laufen.
