ClaraVerse: ein selbst gehosteter Arbeitsbereich für Chat, Agententeams und RAG
Claraverse is a opesource privacy focused ecosystem to replace ChatGPT, Claude, N8N, ImageGen with your own hosted llm, keys and compute. With desktop, IOS, Android Apps.
Auf einen Blick
- Was ist das?
- ClaraVerse bündelt Chat, mehrstufige Agententeams, einen visuellen Workflow-Builder und Wissensdatenbanken in einer selbst betriebenen Anwendung. Der Docker-Compose-Weg lohnt sich, der Einzelcontainer bleibt ohne Sidecars unvollständig.
- Für wen ist es gedacht?
- Wer Chat, Agententeams und RAG auf eigener Hardware betreiben will und Docker Compose mit MySQL, MongoDB, Redis, SearXNG, Qdrant und dem Embeddings-Sidecar aufsetzen kann, findet in ClaraVerse ein zusammenhängendes Paket. Wer nur einen einzelnen Container starten möchte, sollte zuerst prüfen, ob der Verzicht auf den Knowledge-Tab akzeptabel ist, denn ohne Sidecars meldet das System embeddings service unreachable.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 43 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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
Welche Lücke ClaraVerse schließen will
Die README nennt drei Punkte, die in vergleichbaren Chat-Oberflächen laut Projektbeschreibung nebenbei behandelt werden: Agenten, die als Team arbeiten, ein Gedächtnis, das sich wie ein Gedächtnis verhält, und eine Lizenz, die nicht nachträglich Geld verlangt. Das ist eine klare Zielgruppenaussage. Adressiert sind Leute, die bereits Ollama oder LM Studio betreiben und eine Oberfläche darüber wollen, ohne ihre Chats an einen Anbieter zu geben. Der Standard ist lokal gespeicherter Verlauf, verschlüsselte Synchronisierung ist optional. Wer ausschließlich eine Weboberfläche für einen einzelnen lokalen Endpunkt sucht, bekommt hier mehr Bauteile als nötig. Wer dagegen Agententeams mit menschlicher Freigabe und abrufbares Wissen über mehrere Gespräche hinweg braucht, findet beides in derselben Anwendung statt in drei getrennten Diensten.
Crew, Memory und Wissensbasis: die drei tragenden Mechanismen
Crew arbeitet nach dem Muster einer Kartenpipeline. Ein Projekt erhält ein Briefing, danach wird eine Gruppe von Agenten zusammengestellt, und jede Karte kommt vor dem Abschluss zur Prüfung zurück. Die README formuliert das als Gegensatz zur Blackbox: man soll jederzeit wissen, woran gearbeitet wird und warum. Das ist ein Freigabeschritt pro Karte, kein Autopilot.
Memory ist in zwei Stufen geteilt. Angeheftete Einträge werden immer eingefügt, überspringen die Relevanzbewertung und verfallen nie. Alles andere liegt im Recall-Tier und wird über Embedding-Ähnlichkeit gegen das laufende Gespräch abgerufen, sodass nur Passendes in den Kontext gelangt. Ungenutzte Einträge verlieren an Relevanz und archivieren sich selbst. Das Modell ruft search_memory und add_memory mitten im Gespräch auf, also als gewöhnliche Werkzeuge. Gespeichert wird mit AES-256-GCM, der Schlüssel wird pro Nutzer über HKDF abgeleitet. Laut README kann auch ein ClaraVerse-Administrator die Einträge nicht lesen.
Wissensdatenbanken hängen an Qdrant und einem Embeddings-Sidecar. Genau hier liegt die wichtigste Einschränkung des Projekts, siehe unten.
Installation: zwei Wege mit sehr unterschiedlichem Ergebnis
Der Einzeiler für Linux und macOS lautet:
curl -fsSL https://raw.githubusercontent.com/claraverse-space/ClaraVerse/main/cli/install.sh | bash && claraverse init
Der zweite Weg klont das Repository und startet den vollen Stack:
git clone https://github.com/claraverse-space/ClaraVerse.git cd ClaraVerse docker compose -f docker-compose.production.yml up -d
Danach ist die Oberfläche unter http://localhost:3000 erreichbar, der erste registrierte Nutzer wird Administrator. Für den Einzelcontainer gibt die README ein docker run mit den Volumes claraverse-data und claraverse-uploads sowie --add-host=host.docker.internal:host-gateway an. Anpassen lässt sich das über eine .env-Datei neben docker-compose.production.yml, mit CLARAVERSE_PORT für den Port und OLLAMA_BASE_URL beziehungsweise LMSTUDIO_BASE_URL für abweichende Endpunkte. Als Untergrenze nennt die README 4 GB RAM, empfohlen werden 8 GB.
Der Einzelcontainer ist eine Falle
Die README ist an dieser Stelle ungewöhnlich deutlich: Der Einzelcontainer startet, aber der Knowledge-Tab und das Werkzeug search_knowledge brauchen die Sidecars und melden ohne sie embeddings service unreachable. Wer also die schnelle Variante wählt und später RAG erwartet, steht vor einem Feature, das nicht defekt ist, sondern schlicht nicht deployt wurde. Das ist kein Fehler im Code, sondern eine Folge des Deployment-Zuschnitts, und es ist der Punkt, an dem die Entscheidung für oder gegen ClaraVerse tatsächlich fällt. Wer nur chatten will, kommt mit einem Container aus. Wer Wissen abrufen will, braucht MySQL, MongoDB, Redis, SearXNG, Qdrant und den Embeddings-Dienst.
Ein zweiter Stolperstein liegt außerhalb des Projekts. Ollama hört standardmäßig auf 127.0.0.1, was Container nicht erreichen. Die README empfiehlt OLLAMA_HOST=0.0.0.0, bei systemd über sudo systemctl edit ollama und einen Eintrag unter [Service], danach sudo systemctl restart ollama. Ohne diesen Schritt bleibt die automatische Erkennung wirkungslos.
Automatische Erkennung lokaler Anbieter
ClaraVerse sucht selbstständig nach lokalen Anbietern. Für Ollama ist die Vorgabe http://host.docker.internal:11434, für LM Studio http://host.docker.internal:1234. Bei Ollama werden Modelle importiert, ein Anbieter angelegt und die Sichtbarkeit gesetzt, bei LM Studio läuft der Import über eine OpenAI-kompatible Schnittstelle. Die Suche wiederholt sich alle zwei Minuten. Fällt ein Anbieter aus, wird er deaktiviert, kommt er zurück, werden die Modelle erneut importiert. Das ist bequem und zugleich der Grund, warum die OLLAMA_HOST-Einstellung so wichtig ist: Die Erkennung kann nur finden, was erreichbar ist. Praktisch bedeutet der Zwei-Minuten-Takt außerdem, dass ein neu gestartetes Modell nicht sofort erscheint. Die README nennt kein Intervall zum manuellen Auslösen, dieser Punkt bleibt offen.
Clara Agent und der Weg ins Terminal
Im Repository liegt mit clara-agent/ ein Coding-Agent, der im Terminal läuft, Dateien liest, schreibt und ändert sowie Befehle auf der Maschine ausführt. Er nutzt dasselbe Modell und dasselbe Konto wie die Webanwendung. Installiert wird er mit:
claraverse agent install
Danach liegt claracli im PATH, und die Verbindung läuft über /login claraverse. Bemerkenswert ist die Reichweite: derselbe Agent soll auf Desktop, iOS und Android verfügbar sein, was die README über die Aufzählung der Apps andeutet. Ein Agent, der Dateien und Befehle auf dem Rechner ausführt, ist zugleich der Teil mit dem größten Risiko. Die README beschreibt an dieser Stelle keine Sandbox und keine Bestätigungsschranke. Wer ihn einsetzt, sollte das vorher selbst klären.
Wie sich ClaraVerse von Open WebUI unterscheidet
Die README verlinkt einen eigenen Abschnitt claraverse-vs-open-webui, der im vorliegenden Material nicht ausgeführt wird. Aus den beschriebenen Bauteilen lässt sich der Unterschied dennoch benennen. Open WebUI ist eine Chat-Oberfläche vor Modell-Endpunkten. ClaraVerse setzt zusätzlich eine Kartenpipeline mit Freigabe pro Arbeitsschritt, ein zweistufiges Memory-System mit Verfall und Archivierung sowie einen visuellen Workflow-Builder auf. Der Preis dafür ist der Betriebsaufwand: mehrere Datenbanken, eine Suchmaschine und ein Embeddings-Dienst statt eines einzelnen Dienstes vor Ollama. Wer nur chatten möchte, fährt mit Open WebUI deutlich schlanker. Wer Agententeams und Wissensabruf als zusammenhängenden Ablauf braucht, muss bei Open WebUI mehrere Systeme selbst verbinden. Die Entscheidung ist damit eine Frage des Betriebsmodells, nicht des Funktionsumfangs.
Wartung, Lizenz und was vor dem Einsatz zu klären ist
Der Wartungsaufwand liegt nicht im Anwendungscode, sondern in der Umgebung. Ein Stack mit MySQL, MongoDB, Redis, SearXNG, Qdrant und einem Embeddings-Sidecar bringt sechs bewegliche Teile mit, die jeweils eigene Upgrades und Sicherungen benötigen. Die README liefert dafür konkrete Befehle: docker compose -f docker-compose.production.yml logs -f claraverse für die Protokolle, denselben Aufruf mit restart zum Neustart und mit down -v gefolgt von up -d für einen Neuanfang, der alle Daten entfernt. Dieser letzte Befehl ist die wichtigste Zeile für alle, die ein Backup planen: Er löscht die Volumes, also müssen Sicherungen außerhalb der Compose-Datei liegen.
Zur Lizenz ist Vorsicht angebracht. Die Metadaten des Repositorys tragen die Kennung NOASSERTION, das README zeigt ein AGPL-3.0-Badge und verlinkt eine LICENSE-Datei. Die README begründet die Lizenzwahl damit, dass sie nicht nachträglich Geld verlangt, sobald ein Projekt Aufmerksamkeit bekommt. Was das konkret bedeutet, hängt vom Wortlaut der LICENSE-Datei ab, die im vorliegenden Material nicht enthalten ist. Wer ClaraVerse in einen eigenen Dienst einbetten oder geändert weitergeben will, muss diese Datei vorher lesen. Eine rechtliche Einordnung kann dieser Text nicht leisten.
Die Release-Historie zeigt drei Veröffentlichungen am 31. Mai 2026, v0.3.0 mit dem Titel Knowledge bases everywhere und v0.3.1 mit One-line install RAG-ready, dazu v0.2.0 zuvor am selben Tag. Der letzte Push liegt laut Metadaten beim 3. August 2026. Das deutet auf aktive Arbeit hin, sagt aber nichts über Stabilität im Dauerbetrieb. Vor dem Einsatz sollte man den Knowledge-Tab mit dem vollen Compose-Stack gegen die eigene Dokumentenmenge prüfen und die Memory-Einträge in den Einstellungen sichten, weil dort sichtbar wird, was das System automatisch extrahiert hat.
Redaktionelles Fazit
Wer Chat, Agententeams und RAG auf eigener Hardware betreiben will und Docker Compose mit MySQL, MongoDB, Redis, SearXNG, Qdrant und dem Embeddings-Sidecar aufsetzen kann, findet in ClaraVerse ein zusammenhängendes Paket. Wer nur einen einzelnen Container starten möchte, sollte zuerst prüfen, ob der Verzicht auf den Knowledge-Tab akzeptabel ist, denn ohne Sidecars meldet das System embeddings service unreachable. Vor dem Produktiveinsatz ist die LICENSE-Datei zu lesen, weil die Lizenzkennung NOASSERTION lautet und die AGPL-3.0 nur über das Badge im README nahegelegt wird.
Community-Notizen