„Bring your own model and computer provider, or run the complete stack locally.“ Mit diesem Satz beginnt das Readme von Rakazo, und er beschreibt schon den halben Ansatz. Der Rest des Repositories folgt derselben Entscheidung: Der Betreiber bestimmt, welches Sprachmodell denkt und welcher Rechner die Arbeit ausführt. Wer einen KI-Assistenten abonniert, mietet dagegen meist ein möbliertes Zimmer – bequem, aber die Möbel gehören jemand anderem.
Ein gehosteter Assistent ist ein Hotelzimmer: Du kommst an, es ist eingerichtet, du reist ab, und beim nächsten Besuch liegt dein Zeug nicht mehr da. Ein selbst betriebener Agent ist eine eigene Wohnung. Du musst streichen, Möbel schleppen und dich um den Wasserhahn kümmern – aber du entscheidest über die Ablage und den Zugriff. Externe Modell- oder Sprachdienste erhalten weiterhin die Daten, die du an sie sendest. Rakazo versucht, diesen Umzug so kurz wie möglich zu halten.
Was Rakazo ist: ein Bot mit Gedächtnis, nicht nur ein Chatfenster
Der Kern sind persistente Bots. Jeder Bot führt eigene Unterhaltungen, ein eigenes Gedächtnis, eigene Routinen und eine eigene Historie. Das ist keine Fußnote, sondern der Unterschied zwischen einem Werkzeug und einem Gegenüber: Ein Bot, der sich an die letzte Woche erinnert, muss nicht bei jedem Gespräch neu gebrieft werden. Dazu kommt ein Sprachmodus – Antworten vorlesen lassen, diktieren, einen Bot anrufen –, für den du deinen eigenen Schlüssel bei ElevenLabs, OpenAI, Cartesia oder Fish Audio hinterlegst.
Ist der Agent eingerichtet, läuft die Bedienung über den Chat, ähnlich wie bei Grok Bot: Du legst einen Bot an und verwaltest ihn aus dem Gespräch heraus. Erreichbar ist das Ganze im Browser, als Electron-Anwendung auf dem Desktop und als App für iPhone und Android. Die Clients greifen auf dieselbe API zu – es sind nicht drei Produkte, sondern eine Installation mit drei Fenstern.
Bei der Arbeitsteilung wird es konkreter. Bots können Aufgaben an andere Bots delegieren oder kurzlebige Subagenten starten, die eine Teilaufgabe übernehmen und danach wieder verschwinden. Zusammen mit Zugriff auf Browser, Terminal, Dateien und eine grafische Desktop-Oberfläche ergibt das eher eine kleine ausführende Einheit als einen Plauderpartner. Wer das zum ersten Mal liest, denkt an Agenten-Hype. Technisch ist es schlicht: Ein Prozess bekommt Werkzeuge und einen Auftrag.
Eigenes Modell, eigener Rechner: was „Bring your own“ praktisch heißt
Auf der Modellseite bedeutet das: Du hinterlegst deine eigenen Zugangsdaten, etwa über Pi oder einen Anbieter, den du beim Onboarding verbindest, alternativ einen OpenRouter-Schlüssel. Damit entscheidest du, welches Modell welche Aufgabe bekommt. Ein schnelles, günstiges Modell für Routinearbeiten, ein stärkeres für die kniffligen Fälle – diese Wahl liegt bei dir, nicht beim Anbieter des Assistenten.
Auf der Rechnerseite muss der Bot irgendwo laufen, wo er Dateien anfassen und Befehle ausführen darf. Dafür kennt Rakazo mehrere Wege: Docker lokal, E2B, Daytona, CreateOS, Boat oder Railway, dazu einen ausdrücklich als vertrauenswürdig markierten lokalen Rechner. Das ist die Sandbox – ein abgetrennter Raum mit eigener Einrichtung, in dem der Bot arbeiten darf, mit einer vom Anbieter und der Konfiguration abhängigen Trennung vom Hauptsystem. Der ausdrücklich vertrauenswürdige lokale Rechner bietet diese Trennung nicht automatisch.
Innerhalb dieser Räume unterscheidet das Projekt zwei Sorten: gemeinsame Team-Computer, auf denen mehrere Bots und Menschen zusammenarbeiten, und isolierte private Computer für Einzelaufgaben. Bei Railway kommt ein Detail, das die Analogie bestätigt: Beim Stoppen eines Computers wird das portable Home gespeichert und die Sandbox zerstört. Beim nächsten Start entsteht eine neue Sandbox, in der dieses Home wiederhergestellt wird. Die Wohnung wird abgerissen, der Inhalt der Koffer bleibt.
Der kürzeste Weg hinein: ein Installer statt eines Quellcode-Checkouts
Wer nur ausprobieren will, braucht Docker Engine, das Compose-Plugin, curl und OpenSSL. Kein Klonen, keine Node-Installation. Ein Skript lädt die Compose-Dateien, erzeugt eine .env mit zufälligen Secrets und startet den Stack. Danach öffnest du http://127.0.0.1:5173, legst ein Konto an und verbindest ein Modell. Lokale Docker-Computer sind standardmäßig aktiv, weitere Anbieter lassen sich über passende Schlüssel nachrüsten.
Für eingeschränkte Netze gibt es Schalter: eine andere Download-Basis über RAKAZO_DOWNLOAD_BASE, das Überspringen vorhandener Compose-Dateien oder einen Spiegel des Bootstrap-Skripts. Wer die Installation lieber von einem Agenten begleiten lässt, nimmt die SETUP_PROMPT.md. Das Projekt dokumentiert also beides: wie man es installiert und wie man ein anderes Modell damit beauftragt. Standardmäßig zieht der Installer den Image-Tag edge für linux/amd64 und linux/arm64.
Auch der Desktop-Client kann den Stack selbst hochziehen. Beim ersten Start fragt er, ob Rakazo auf diesem Rechner laufen oder sich mit einer bestehenden Instanz verbinden soll. Für den lokalen Weg braucht er Docker Desktop, OrbStack oder Docker Engine und startet dieselben Compose-Dateien im Datenverzeichnis der App. Der Stack läuft nach dem Schließen weiter und wird über den Menüpunkt „Stop Local Stack“ beendet. Öffentliche Server müssen HTTPS sprechen; HTTP gilt nur für Loopback und private LAN-Adressen, nicht für Link-Local.
Auf einem Server: Bots, die weiterlaufen, wenn der Laptop zuklappt
Interessant wird es, wenn der Agent nicht auf dem eigenen Rechner schläft. Der Installer läuft auch auf einem VPS; mit --prepare-only bereitest du ihn vor, trägst in der .env einen SANDBOX_PROVIDER samt Schlüssel und RAKAZO_HOST ein und startest ihn erneut. Danach kommt HTTPS vor Port 5173 – die Dokumentation beschreibt die Caddy-Konfiguration und die Härtung des Hosts –, und im Desktop-Client wählst du „Existing instance“ mit der https://-Adresse.
Ab dann greifen Desktop, Handy und Browser auf dieselbe Instanz zu. Der Rechner zu Hause darf aus sein, der Bot arbeitet weiter. Hier wird aus einem Experiment ein Werkzeug, auf das man sich im Alltag verlässt. Und hier beginnt Betriebsverantwortung: Updates, Backups, Zertifikate, Schlüssel.
Beim Railway-Anbieter gelten zusätzliche Bedingungen. Die Live-Ansicht und der Desktop brauchen privates Networking, und ein eigenes Projekt oder wenigstens eine eigene Umgebung für Sandboxes ist ausdrücklich empfohlen, getrennt von App und Datenbank. Das Token sollte so eng wie möglich geschnitten sein, ein Team- oder Workspace-Token statt eines persönlichen Kontos. Solche Sätze stehen selten aus Zierde im Readme.
Quellcode, Secrets und die Details, die später Ärger machen
Wer aus dem Repository baut, braucht Node.js in einer der unterstützten Linien – 22.x ab 22.22.2, 24.x oder 26 und neuer; die ungeraden Versionen 23 und 25 sind ausgenommen –, dazu pnpm 9 und Docker. Die .env verlangt unabhängige Zufallswerte für BETTER_AUTH_SECRET, ENCRYPTION_KEY und SCREEN_PROXY_SECRET, für Docker-Sandboxes zusätzlich ein eigenes SANDBOX_SUPERVISOR_TOKEN. Geteilte Secrets sind hier keine Abkürzung, sondern ein offenes Tor.
Ein Klassiker, der viele überrascht: Das Postgres-Volume behält Benutzer, Passwort und Datenbank aus der ersten Initialisierung. Wer später die Werte in der .env ändert, ändert damit nicht die Datenbank. Und docker compose down -v löscht den gesamten Zustand. Klingt banal, kostet aber regelmäßig einen Nachmittag.
Bei den Integrationen bleibt das Projekt vorsichtig. Composio und Pipedream Connect sind optionale Kataloge; ohne sie lassen sich trotzdem HTTPS-MCP-Server, Treg-Endpunkte oder OpenAPI-Dokumente unter Integrations hinzufügen. Zugangsdaten von Connectoren werden serverseitig verschlüsselt und von der API nie zurückgegeben. Treg wird nutzungsbasiert abgerechnet, Selbsthoster bringen ihren eigenen Token mit, und wer Treg in ein gehostetes Produkt einbettet, sollte die Bedingungen lesen – für Weiterverkauf ist eine schriftliche Vereinbarung vorgesehen.
Kontrolle gegen Aufwand
Rakazo ist in der Beta, und das merkt man an der Art, wie dokumentiert wird: sehr genau bei Installation, Secrets und Isolationsgrenzen, zurückhaltend bei Zusagen. Die Lizenz ist Apache 2.0, der Austausch läuft über Discord, und die Liste der Vergleichsprodukte im Readme ist ehrlich geführt – von Grok Bot über Meta Muse und OpenAI Dots bis zu OpenClaw und Hermes Agent. Es gibt also Alternativen, und einige davon sind ebenfalls offen.
Der Unterschied liegt weniger im Funktionsumfang als in der Konsequenz des Selbstbetriebs. Ein gehosteter Assistent ist in fünf Minuten da und in fünf Minuten weg. Eine eigene Instanz ist in einer Stunde da und dann deine Verantwortung. Dafür bestimmst du, welches Modell denkt, welcher Rechner handelt und wo die Daten liegen.
Wenn du einen Agenten suchst, der ein paar Aufgaben erledigt und dafür eine kleine Monatsgebühr kostet, ist das hier der umständlichere Weg. Wenn du einen Bot brauchst, der dauerhaft läuft, sich an Zusammenhänge erinnert und in einer Umgebung arbeitet, die du kontrollierst, lohnt der Blick ins Repository. Nimm dir den Installer, setz es lokal auf, verbinde ein Modell und schau nach einer Woche nach, ob der Bot noch weiß, worum es ging.
Quelle: github.com
