Rakazo: selbst gehostete KI-Teammitglieder mit eigener Sandbox

Was Rakazo löst und für wen es gedacht ist

Ein Bot, der nach jedem Neustart bei null anfängt, ist für wiederkehrende Aufgaben wenig brauchbar. Rakazo setzt genau dort an: Die Dokumentation beschreibt Bots mit eigenen Gesprächen, Erinnerungen, Routinen und Verlauf. Der Bot existiert also über eine Sitzung hinaus und kann sich auf frühere Läufe beziehen. Dazu kommt eine Ausführungsumgebung. Bots erhalten laut Funktionsliste Zugriff auf Browser, Terminal, Dateien und eine grafische Desktop-Oberfläche, wahlweise auf einem geteilten Team-Rechner oder auf einem isolierten privaten Rechner. Zielgruppe sind damit nicht Nutzer, die einen einzelnen Chatverlauf wollen, sondern Teams, die wiederkehrende Arbeit delegieren und dabei kontrollieren möchten, wo diese Arbeit ausgeführt wird. Der Anspruch, die eigene Infrastruktur zu behalten, zeigt sich im Aufbau: Modellzugang und Rechneranbieter sind austauschbar, und der komplette Stack lässt sich lokal betreiben. Rakazo befindet sich laut README in der Beta, was für die Bewertung des Reifegrads wichtiger ist als jede Versionsnummer.

Wie ein Bot an Modell und Rechner kommt

Die Modellanbindung läuft über Pi. Rakazo liefert selbst keine Modellzugänge mit, sondern reicht die Zugangsdaten des Betreibers weiter. Das ist der Unterschied zu einem fertigen Assistenten mit festgelegtem Anbieter: Die Wahl des Modells ist eine Konfigurationsfrage, kein Merkmal des Produkts. Für die Ausführung gibt es mehrere Wege. Der Installer aktiviert lokale Docker-Rechner standardmäßig, im README steht dazu der Hinweis, dass Local Docker computers on by default sind. Wer Rechenleistung auslagern will, setzt SANDBOX_PROVIDER auf e2b, daytona oder box und hinterlegt den passenden API-Schlüssel. Die Oberfläche selbst ist ein Client der Rakazo-API, die Web-App, die Electron-Anwendung und die Expo-App sprechen also mit demselben Backend. Der Serverteil besteht aus Hono und oRPC, PostgreSQL mit Prisma, Better Auth für die Anmeldung und Graphile Worker für Hintergrundaufgaben. Diese Aufteilung erklärt, warum ein Bot weiterläuft, wenn der Desktop geschlossen wird: Die Ausführung hängt am Backend, nicht am Client. Bots können außerdem an andere Bots oder an kurzlebige Subagenten delegieren, was die Frage aufwirft, wie viele gleichzeitige Ausführungen eine einzelne Sandbox tragen soll. Das README beantwortet das nicht.

Installation in zwei Varianten

Für den schnellen Einstieg ist kein Quellcode nötig. Benötigt werden Docker Engine, das Compose-Plugin, curl und OpenSSL. Der Installer wird geladen und ausgeführt:

mkdir -p rakazo && cd rakazo && curl -fsSLO https://raw.githubusercontent.com/elie222/rakazo/main/infra/compose/install-images.sh && bash install-images.sh

Laut README lädt das Skript die Compose-Dateien, erzeugt eine .env mit zufälligen Secrets und startet Rakazo. Ein vorhandenes .env bleibt bei erneutem Lauf erhalten. Danach ist die Oberfläche unter http://127.0.0.1:5173 erreichbar, wo ein Konto angelegt und ein Modell verbunden wird. Das Standard-Image-Tag ist edge, also Builds aus main, verfügbar für linux/amd64 und linux/arm64. Für einen Server auf einem VPS gilt derselbe Installer, aber mit einem Zwischenschritt: erst bash install-images.sh --prepare-only, dann in der .env SANDBOX_PROVIDER auf box, e2b oder daytona setzen, RAKAZO_HOST auf die eigene Domain, und anschließend bash install-images.sh erneut ausführen. Vor Port 5173 gehört HTTPS, die Anleitung nennt dafür Caddy. In der Desktop-App wird dann Existing instance gewählt und die https-Adresse eingetragen.

Wer aus dem Quellcode arbeitet, braucht Node.js 22.22.2 oder neuer in der 22er-Linie, Node.js 24.x oder Node.js 26 oder neuer, dazu pnpm 9 und Docker. Die Versionen 23.x und 25.x werden ausdrücklich nicht unterstützt, eine Einschränkung, die bei automatisierten Build-Umgebungen leicht übersehen wird. Nach dem Klonen und cp .env.example .env müssen mehrere Werte gesetzt werden: POSTGRES_PASSWORD, derselbe Wert in DATABASE_URL, außerdem BETTER_AUTH_SECRET, ENCRYPTION_KEY und SCREEN_PROXY_SECRET als voneinander unabhängige Zufallswerte. Für Docker-Sandboxes kommt ein eigener SANDBOX_SUPERVISOR_TOKEN hinzu. Der Start erfolgt über docker compose mit den Dateien infra/compose/docker-compose.yml und infra/compose/docker-compose.postgres-host.yml, gefolgt von pnpm install, pnpm db:generate, pnpm db:migrate, pnpm sandbox:build und pnpm dev. Das Overlay postgres-host veröffentlicht 127.0.0.1:5433, damit Werkzeuge auf dem Host die Datenbank erreichen. Ohne Overlay bleibt Postgres netzintern.

Postgres-Volume, Secrets und die Kosten des Upgrades

Ein Detail mit Folgen: Ein bereits vorhandenes pgdata-Volume behält Benutzer, Passwort und Datenbank aus der ersten Initialisierung. Wer POSTGRES_PASSWORD in der .env später ändert, ändert damit nicht die Datenbank. Das README nennt zwei Wege, damit umzugehen: die ursprünglichen Werte in der .env behalten oder die Rolle per ALTER ROLE anpassen beziehungsweise umbenennen. Das Volume neu anzulegen ist nur nach einem Backup sinnvoll, und docker compose down -v löscht den gesamten Postgres-Zustand. Dasselbe gilt für die Secrets: BETTER_AUTH_SECRET, ENCRYPTION_KEY und SCREEN_PROXY_SECRET werden bei der Einrichtung erzeugt. Wer sie nachträglich rotiert, muss prüfen, welche Daten mit ENCRYPTION_KEY verschlüsselt wurden, denn laut README werden Connector-Zugangsdaten serverseitig verschlüsselt und nie über die API zurückgegeben. Ein Schlüsselwechsel ohne Migrationspfad ist damit ein Datenverlustrisiko, nicht eine reine Konfigurationsänderung. Updates laufen über neue Image-Tags. Installierte Desktop-Builds binden den Image-Tag an ihre eigene Version, unverpackte Builds ziehen edge. Das bedeutet: edge kann sich jederzeit ändern, und wer diesen Kanal nutzt, betreibt faktisch einen Rolling-Release ohne Zwischenstufe. Die Versionshistorie zeigt drei Releases innerhalb von drei Tagen Anfang September 2026 (v0.1.4 bis v0.1.6), was für ein Beta-Projekt mit hoher Änderungsrate spricht. Wer Stabilität braucht, sollte einen festen Tag pinnen statt edge zu folgen.

Integrationen: Composio, Pipedream, MCP und Treg

Für Anwendungsanbindungen gibt es zwei verwaltete Kataloge. Composio wird über COMPOSIO_API_KEY aktiviert, Pipedream Connect über das Trio PIPEDREAM_CLIENT_ID, PIPEDREAM_CLIENT_SECRET und PIPEDREAM_PROJECT_ID. Beide sind optional. Ohne sie können Nutzer laut README einen HTTPS-MCP-Server, einen Treg-Endpunkt oder ein OpenAPI-JSON-Dokument über den Bereich Integrations selbst hinzufügen. Das ist der pragmatischere Weg für Betreiber, die keine weiteren Dienste einbinden wollen, und gleichzeitig der Punkt, an dem die Angriffsfläche wächst: Jede selbst installierte Tool-Quelle ist Code, der im Namen des Bots handelt. Eine Besonderheit ist Treg. Es wird nutzungsabhängig abgerechnet, Selbsthoster bringen ihren eigenen Treg-Token mit, und die Integrationsbedingungen von Treg verlangen laut README für gehosteten Weiterverkauf eine schriftliche Vereinbarung. Wer Rakazo also als Dienst für Dritte betreibt und Treg darin einbettet, muss das vorher klären. Für die Lizenz gilt: Rakazo selbst steht unter Apache-2.0, was kommerzielle Nutzung und Änderung erlaubt. Diese Lizenz erstreckt sich aber nicht auf die eingebundenen Dienste, und die externe Vereinbarung für Treg bleibt davon unberührt. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass hier zwei Ebenen auseinanderfallen.

Grenzen und wann Rakazo das falsche Werkzeug ist

Die größte Einschränkung ist der Betriebsaufwand. Rakazo ist kein einzelnes Binary, sondern ein Verbund aus Postgres, Backend, Worker, Sandbox-Images und mehreren Secrets. Wer nur gelegentlich einen Assistenten befragt, bezahlt dafür mit Wartung, ohne etwas zu gewinnen. Ein zweiter Punkt betrifft die Ausführungsumgebung. Geteilte Team-Rechner bedeuten, dass mehrere Bots auf derselben Maschine arbeiten. Das README beschreibt diese Option, geht aber nicht darauf ein, wie sich Bots dort gegenseitig beeinflussen oder wie Dateisystemzugriffe zwischen ihnen getrennt werden. Wer starke Isolation braucht, sollte auf private Rechner oder einen externen Anbieter setzen und diese Frage vor der Einführung selbst prüfen. Drittens die Reife: Das Projekt bezeichnet sich als Beta, die Release-Kadenz ist hoch, und die öffentliche Dokumentation deckt Installation und Deployment ab, nicht den Dauerbetrieb unter Last. Für Umgebungen mit Verfügbarkeitszusagen ist das ein Risiko, das sich nicht durch Konfiguration beheben lässt. Schließlich die Clients: Die Electron-App kann den Stack lokal installieren und weiterlaufen lassen, nachdem die App beendet wurde, aber sie verlangt Docker Desktop, OrbStack oder Docker Engine. Entwickler, die pnpm dev nutzen, sollen laut README stattdessen Existing instance mit http://127.0.0.1:5173 wählen. Öffentliche Server müssen HTTPS verwenden, HTTP wird nur für Loopback- und private LAN-Adressen akzeptiert, nicht für Link-Local-Adressen.

Was andere anders machen: Open WebUI als Gegenbeispiel

Als Vergleich bietet sich Open WebUI an, eine verbreitete selbst gehostete Chat-Oberfläche mit austauschbaren Modell-Backends. Der Unterschied liegt nicht in der Modellwahl, die beide ermöglichen, sondern im Ausführungsmodell. Open WebUI ist eine Chat-Oberfläche mit Werkzeugaufrufen, die im Prozess der Anwendung ablaufen. Rakazo trennt dagegen den Bot von der Umgebung, in der er handelt, und führt ihn in einer eigenen Sandbox aus, lokal in Docker oder bei einem externen Anbieter. Daraus folgen die Merkmale, die Rakazo von einer Chat-Oberfläche unterscheiden: persistente Routinen, Zugriff auf einen grafischen Desktop, Delegation an Subagenten. Der Preis ist ein deutlich größerer Betriebsapparat. Wer nur Dialoge mit einem eigenen Modell führen will, kommt mit Open WebUI mit weniger beweglichen Teilen aus. Wer dagegen will, dass ein Bot Dateien anlegt, im Browser arbeitet und über Wochen denselben Kontext behält, stößt bei einer reinen Chat-Oberfläche an eine Grenze, die sich nicht durch Prompts verschieben lässt.

Redaktionelles Fazit

Rakazo passt zu Teams, die Bots mit dauerhaftem Zustand, Rechnerzugriff und eigener Modellanbindung brauchen und den Betrieb selbst tragen wollen, sei es auf einem VPS oder lokal per Electron. Wer nur einen Chatbot ohne Ausführungsumgebung sucht, ist hier falsch, und für Einzelpersonen ist der Betriebsaufwand mit Postgres, Sandbox-Images und Secrets hoch. Vor dem ersten produktiven Einsatz sollte man den Installer ohne Ausführung starten und die erzeugte .env prüfen, konkret POSTGRES_PASSWORD, BETTER_AUTH_SECRET, ENCRYPTION_KEY, SCREEN_PROXY_SECRET und SANDBOX_SUPERVISOR_TOKEN, außerdem klären, ob der eigene Anwendungsfall den Treg-Token braucht, weil Treg nutzungsabhängig abgerechnet wird und für gehosteten Weiterverkauf laut den Integrationsbedingungen von Treg eine schriftliche Vereinbarung verlangt.

Offizielle Quellen

1. elie222/rakazo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases