Rakazo auf eigenem VPS hosten: Anleitung

Was Rakazo beim Self-Hosting tatsächlich ausführt

Self-Hosting von Rakazo bedeutet, fünf Komponenten auf einem Linux-Server zu betreiben: PostgreSQL, einen Graphile Worker-Prozess, die API, die Web-App sowie einen Sandbox-Container für jeden aktiven Bot. Rakazo ist eine Open-Source-Alternative zu Grok Bot, die von elie222 unter der Apache 2.0-Lizenz veröffentlicht wurde. Jeder Bot erhält einen eigenen Thread, einen eigenen Rechner, eigenen Arbeitsspeicher und eine eigene Historie; zudem kann er Peers oder kurzlebige Sub-Agents starten. Falls Begriffe wie Arbeitsspeicher, Sub-Agent und Tool-Call in diesem Zusammenhang unbekannt sind, lohnt es sich, einen Nachmittag in einen strukturierten Pfad zur Funktionsweise von Agents zu investieren. Die meisten der folgenden Einstellungen sind erst verständlich, wenn man nachvollziehen kann, was ein Bot beim Startvorgang tut.

Dieser letzte Punkt ist der Grund, warum diese Anwendung auf einem VPS (Virtual Private Server) und nicht auf einem Desktop-Rechner laufen sollte. Ein Bot, der Arbeitsspeicher belegt und geplante Aufgaben ausführt, muss auch dann erreichbar sein, wenn Sie schlafen. Ein Laptop, der in den Standby-Modus wechselt, unterbricht die Warteschlange.

Rakazo befindet sich mit Stand August 2026 in einer frühen Beta-Phase; betrachten Sie dies daher eher als funktionierendes Setup denn als fertiges Produkt. Der gesamte Stack basiert auf TypeScript: React 19 und Vite für die Web-App, Hono für die API, Postgres mit Prisma, Better Auth für die Benutzerverwaltung und Graphile Worker für Hintergrundjobs. Graphile Worker speichert seine Warteschlange direkt in Postgres, sodass weder Redis noch ein zweiter Datenspeicher erforderlich sind. .env.example setzt WAKEUP_DRIVER=graphile voraus, was bedeutet, dass das Aufwachen eines Bots ein Postgres-basierter Job ist. Wenn Sie Postgres stoppen, werden auch alle geplanten Bot-Aktionen beendet. Falls Sie einen Agent lieber aus Einzelteilen zusammenstellen möchten, anstatt das Produkt eines anderen zu verwenden, ist der Aufbau eines eigenen Agents aus Komponenten der alternative Weg.

Warum ein 1 GB Plan hierfür nicht ausreicht

Zählen Sie die Prozesse. Postgres ist einer. Die API ist ein Node-Prozess. Der Worker ist ein zweiter. Die Web-App ist ein dritter. Der Sandbox-Supervisor ist ein vierter. Jeder laufende Bot erhält zudem einen Container, der einen grafischen Linux-Desktop und einen Browser enthält.

Die Self-Hosting-Dokumentation des Projekts nennt eine ehrliche Zahl: Eine Maschine mit 2 vCPU und 4 GB RAM reicht für die API, den Worker und Postgres aus, wenn E2B die Bot-Desktops hostet. Das ist der Wert allein für die Control Plane, während der ressourcenintensive Teil extern läuft. Setzen Sie SANDBOX_PROVIDER=docker, wandern diese Desktops auf Ihren VPS; 4 GB werden damit zum absoluten Minimum statt zum Zielwert. Beginnen Sie bei 8 GB, wenn Sie mehr als einen Bot gleichzeitig aktiv halten wollen, und messen Sie den tatsächlichen Bedarf mit docker stats, während ein Bot arbeitet. Der Browser innerhalb der Sandbox ist der entscheidende Faktor für den Speicherverbrauch; ein Datenblatt wird Ihnen diesen Wert nicht verraten. Für die allgemeine Methode zur Dimensionierung eines Servers für Agenten-Aufgaben erläutert wie viel RAM und CPU ein Agenten-VPS tatsächlich benötigt die Messung im Detail.

Eine Einstellung verhindert, dass sich die Situation verschlimmert. .env.example wird mit SANDBOX_IDLE_MS=600000 ausgeliefert, wobei der Kommentar besagt, dass E2B-Computer nach dieser Anzahl an Millisekunden im Leerlauf pausiert oder Docker-Container gestoppt werden. Nach zehn Minuten Inaktivität wird der Computer entfernt. Der minimal zulässige Wert beträgt 30000. Ohne diese Einstellung würde jeder Bot, den Sie jemals geöffnet haben, dauerhaft Arbeitsspeicher belegen.

Der Festplattenspeicher zählt ebenfalls. Das Sandbox-Image, die Node-Module und das Postgres-Volume teilen sich eine Festplatte, daher sind 40 GB ein sinnvoller Ausgangspunkt.

Fixieren Sie eine Version vor dem Klonen

Rakazo entwickelt sich schnell und main ist kein Release. Zum Stand vom 16. August 2026 enthält das Repository genau ein Tag, v0.1.0-beta, das am 13. August 2026 veröffentlicht und als Prerelease markiert wurde.

git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb
git log -1 --format='%H %ci'

Der Commit ist der, auf den v0.1.0-beta verweist. Fixieren Sie den Commit statt des Branches oder Tags. Ein Branch ändert sich beim nächsten git pull, und ein Tag ist eine veränderbare Bezeichnung, die ein Maintainer neu zuweisen kann. Keiner von beiden identifiziert daher einen Tree, zu dem Sie zurückkehren können. Eine Commit-ID kann nicht geändert werden. Notieren Sie sie zusammen mit den anderen Serverdaten. Wenn ein Upgrade etwas beschädigt, besteht die schnelle Lösung aus git checkout <old commit> und einem Neuaufbau. Das funktioniert nur, wenn Sie wissen, welcher Commit funktioniert hat. Diese präzise Fixierung ist ein Aufwand der Beta-Phase und keine allgemeingültige Regel. Ein Projekt mit geplanten Releases kann stattdessen auf einem veröffentlichten Tag gehalten werden. Das ist beispielsweise bei einem kleineren Self-Hosted-Stack wie openGym der Fall.

Anforderungen: Node 22, pnpm 9 und Docker

node -v
pnpm -v
docker --version

package.json deklariert "engines": { "node": ">=22" } und "packageManager": "pnpm@9.15.0", daher muss node -v die Version v22 oder höher ausgeben. Das Node-Paket im Ubuntu-Archiv ist in der Regel älter; installieren Sie daher über NodeSource oder nvm. pnpm wird zusammen mit Node über corepack bereitgestellt:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine inklusive des compose-Plugins deckt den Rest ab; Ihr Benutzer muss den Daemon erreichen können. Wenn docker ps mit permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock antwortet, fügen Sie Ihren Benutzer der Gruppe docker hinzu und öffnen Sie eine neue Login-Shell. Bedenken Sie die Konsequenzen: Die Mitgliedschaft in docker ist gleichbedeutend mit root-Rechten auf dem System, da jedes Mitglied dieser Gruppe einen Container starten kann, der das Dateisystem des Hosts einbindet.

Konfiguration der .env-Datei und Start von Postgres

cp .env.example .env
chmod 600 .env

Zwei Werte müssen geändert werden, bevor der Dienst aus dem Netzwerk erreichbar ist. .env.example liefert BETTER_AUTH_SECRET=replace-with-32-plus-character-secret und ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase aus. Rakazo lehnt diese Platzhalterwerte außerhalb der Entwicklung ab. Eine nur teilweise konfigurierte Bereitstellung schlägt daher lautstark fehl, anstatt mit einem im Repository veröffentlichten Geheimnis zu laufen.

openssl rand -base64 48
openssl rand -hex 32

Starten Sie anschließend die Datenbank separat und führen Sie die Migrationen aus.

docker compose --env-file .env -f infra/compose/docker-compose.yml up postgres -d
pnpm install
pnpm db:generate
pnpm db:migrate
pnpm sandbox:build

pnpm sandbox:build erstellt das Bot-Container-Image, das in package.json als docker build -t rakazo/computer:local infra/sandboxes/computer definiert ist. Da es sich um ein grafisches Image handelt, lädt der erste Build-Vorgang viele Daten herunter und nimmt Zeit in Anspruch. Überprüfen Sie mit docker image ls rakazo/computer, ob das Image vorhanden ist; der Befehl sollte eine Zeile ausgeben.

Die Compose-Datei veröffentlicht Postgres unter 127.0.0.1:5433:5432, was nur auf dem Loopback-Interface verfügbar ist. Belassen Sie es dabei. Die Entwicklungs-Anmeldedaten lauten rakazo:rakazo und befinden sich im Repository. Ein Postgres-Port, der mit einem veröffentlichten Passwort aus dem Internet erreichbar ist, wird innerhalb weniger Stunden von Scannern gefunden. Die Produktions-Compose-Datei liest stattdessen POSTGRES_PASSWORD; setzen Sie diesen Wert auf eine zufällige Zeichenfolge, sobald Sie diesen Schritt erreichen.

Der erste Start

pnpm dev

Dies startet vier Komponenten: die API auf Port 3100, den Graphile Worker, die Vite-Webanwendung auf 5173 und den Sandbox-Supervisor auf 7091. Die Anwendung ist unter http://127.0.0.1:5173 erreichbar; dort sollte eine Anmeldeseite erscheinen.

Auf einem VPS sitzen Sie nicht direkt vor der Maschine. Sie sollten Port 5173 daher nicht öffentlich freigeben, um darauf zuzugreifen. Leiten Sie die Ports stattdessen per SSH (Secure Shell) von Ihrem lokalen Rechner weiter.

ssh -L 5173:127.0.0.1:5173 -L 3100:127.0.0.1:3100 you@your-server

Achten Sie auf den Unterschied zwischen den beiden Ausführungsmethoden. pnpm dev startet Vite auf dem Host und bindet es lokal. Der Dienst web in der Compose-Datei veröffentlicht 5173:5173 auf allen Schnittstellen. Wenn Sie den vollständigen Entwicklungs-Stack per Compose auf einem öffentlichen VPS starten, ist die Anwendung exponiert. Verwenden Sie daher für alles, was dauerhaft läuft, die Produktionsdatei und den zugehörigen Reverse Proxy.

Welcher Sandbox-Anbieter ist auf einem Server sicher?

Dies ist die eine Einstellung, die korrekt konfiguriert sein muss. SANDBOX_PROVIDER in .env akzeptiert vier Werte.

• docker ist die Standardeinstellung. Jeder Bot erhält einen eigenen Container auf Ihrer Maschine, der aus dem von pnpm sandbox:build erstellten Image gebaut wird. Dies ist das schnellste Self-Hosted-Setup.
• e2b führt die Bot-Computer auf E2B aus und benötigt E2B_API_KEY. Das Projekt empfiehlt dies für öffentliche oder Multi-User-Bereitstellungen, da es die Bot-Computer vom Host trennt, auf dem Ihre API und Ihre Datenbank laufen.
• desktop führt die Befehle des Bots direkt auf dem API- und Worker-Host aus. Die Anweisung im Repository ist unmissverständlich: Verwenden Sie dies nicht auf einem öffentlichen oder gemeinsam genutzten Server.
• fake ist ein In-Process-Emulator für Tests. Es handelt sich nicht um eine Laufzeitumgebung.

Nehmen Sie die Warnung zum Desktop-Modus wörtlich. Im Desktop-Modus gibt es keinerlei Isolationsgrenze. Der Bot führt Shell-Befehle als der Benutzer aus, der den API-Prozess startet – mit dessen Home-Verzeichnis, dessen SSH-Schlüsseln, dessen Cloud-Anmeldedaten und dessen .env. Text auf einer Webseite, die der Bot liest, wird zu einem Befehl auf Ihrem Server. Der Desktop-Modus auf einem Server ist der Weg, wie ein Bot in den Besitz Ihrer Anmeldedaten gelangt. Verwenden Sie ihn nur auf einer Maschine, an der Sie physisch sitzen, oder gar nicht. Der Wechsel des Anbieters setzt lediglich einen Container um den Pfad der Webseite, anstatt ihn zu schließen, und einem Bot ein eigenes SearXNG-Such-Backend zuzuweisen deckt dieselbe Angriffsfläche von der Suchseite her ab.

docker stellt eine echte, wenn auch unvollkommene Grenze dar. Ein Bot kann die Dateien eines anderen Bots nicht lesen, da jeder einen eigenen Container besitzt. Der Supervisor, der diese Container erstellt, bindet jedoch /var/run/docker.sock ein, und die Kontrolle über den Docker-Socket des Hosts bedeutet die Kontrolle über den Host selbst. Halten Sie den Supervisor daher privat. .env.example dokumentiert SANDBOX_SUPERVISOR_TOKEN als optionales, separates Dienst-Credential, das standardmäßig auf BETTER_AUTH_SECRET gesetzt ist, wenn es leer bleibt. Das bedeutet: Wenn Sie dieses Secret auf dem Platzhalter belassen, schützen Sie den Container-erstellenden Dienst mit einer Zeichenfolge, die jeder auf GitHub lesen kann. Setzen Sie beide Werte. Für die stärkste hier verfügbare Trennung verwenden Sie e2b oder stellen Sie Rakazo eine Maschine bereit, auf der sich nichts anderes befindet. Dies entspricht der Logik hinter dem Ausführen von Coding-Agenten in einer wegwerfbaren VM: Der günstigste Weg, einen Fehler eines Agenten zu überstehen, besteht darin, dass seine Maschine wertlos ist.

Wo werden Modell-API-Keys hinterlegt?

Rakazo bietet keine verwaltete Abrechnung für Modelle an. Sie müssen Ihren eigenen Key mitbringen. .env.example setzt PI_DEFAULT_PROVIDER=openrouter, daher ist OPENROUTER_API_KEY der übliche Ort dafür; Provider-Keys funktionieren über dieselbe Einstellung.

Bewahren Sie den Key in .env auf und halten Sie ihn aus allen Dateien fern, die Sie committen. Beide compose-Befehle im Repository übergeben --env-file .env, sodass die Werte die Container erreichen, ohne jemals in eine YAML-Datei geschrieben zu werden, die von git nachverfolgt wird. Sie können OPENROUTER_API_KEY auch leer lassen und den Key während des Onboardings in der App einfügen. Das ist ein weiterer Grund, warum ENCRYPTION_KEY einen echten Zufallswert anstelle des mitgelieferten Platzhalters benötigt.

Legen Sie beim Provider ein Ausgabenlimit für den Key fest, bevor ein Bot ihn jemals verwendet. Ein Bot, der in einer Schleife läuft, ist ein Bot, der Kosten verursacht. Ein Limit pro Key ist die einzige Sicherheitsmaßnahme, die nicht davon abhängt, ob Sie das System überwachen. Geben Sie diesem Key einen eigenen Namen, damit Sie ihn separat widerrufen können. Wenn Sie dies für ein Team und nicht für sich selbst einrichten, ist OneCLIs zentrales Gateway vor den Agenten aller Nutzer eine andere Antwort auf dasselbe Problem, da Provider-Keys so an einem zentralen Ort verwaltet werden, anstatt einen Key pro Person zu verwenden.

Vom Entwicklungsmodus zum Dauerbetrieb

Das Repository enthält eine produktive compose-Datei, die Postgres, die API, den Worker, die Web-App und Caddy für automatisch bezogene TLS-Zertifikate (Transport Layer Security) ausführt. Für die Bot-Computer wird E2B vorausgesetzt.

sudo DEPLOY_USER=deploy bash infra/compose/harden-host.sh
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

harden-host.sh deaktiviert SSH-Passwort-Logins, setzt UFW-Regeln (Uncomplicated Firewall) für SSH, HTTP und HTTPS, aktiviert fail2ban und wendet AppArmor-Profile an. Lesen Sie das Skript vor der Ausführung, da es die Art und Weise Ihres Logins ändert. Lassen Sie während der Ausführung eine zweite SSH-Sitzung geöffnet.

Die produktive .env erfordert mehr Ressourcen als die Entwicklungsumgebung. Die Dokumentation zum Self-Hosting führt diese Mindestanforderungen auf.

NODE_ENV=production
RAKAZO_HOST=app.example.com
BETTER_AUTH_URL=https://app.example.com
WEB_ORIGIN=https://app.example.com
API_URL=https://app.example.com
POSTGRES_PASSWORD=<random>
BETTER_AUTH_SECRET=<random>
ENCRYPTION_KEY=<random>
E2B_API_KEY=<your key>
OPENROUTER_API_KEY=<your key>
SANDBOX_PROVIDER=e2b
AGENT_RUNTIME=pi
DATA_DIR=/data

Legen Sie einen A-Record auf den Server, bevor Sie das erste up ausführen. Caddy fordert ein Zertifikat für den in RAKAZO_HOST angegebenen Namen an. Die Anforderung schlägt fehl, wenn der Name nicht auf diesen Server auflöst oder Port 80 nach außen geschlossen ist.

Setzen Sie außerdem SIGNUP_ALLOWLIST=you@example.com. SIGNUPS_ENABLED=true ist die Standardeinstellung; eine Instanz unter einem öffentlichen Namen akzeptiert daher Registrierungen von jedem, der sie findet, und jeder neue Account erhält einen Computer. Nutzen Sie zuerst eine Allowlist. Sie können diese später lockern, falls gewünscht. Falls Sie bereits mehrere Dienste auf demselben Server betreiben und lieber eine zentrale Benutzerliste statt einer Allowlist pro Anwendung pflegen möchten, verlagert das Vorschalten einer Authentik-Instanz diese Entscheidung auf den Proxy, auch wenn dies vor den eigenen Better-Auth-Accounts von Rakazo sitzt, anstatt sie zu ersetzen.

Betrachten Sie docs/self-host.md im Repository als maßgeblich für Produktionseinstellungen, da sich diese Datei mit dem Code ändert, diese Anleitung jedoch nicht. Da Compose die Arbeit übernimmt, gelten die üblichen Regeln, und die Grundlagen zu Docker Compose für einen VPS erläutern, warum --env-file und benannte Volumes wichtiger werden, sobald ein Stack über Monate hinweg ohne manuelle Eingriffe laufen soll.

Backups

Postgres und das Verzeichnis data/ bilden die gesamte Instanz.

./scripts/backup.sh
./scripts/restore.sh backups/BACKUP_TIMESTAMP

backup.sh erstellt Dumps von Postgres und archiviert data/. Für ein System, auf das Sie angewiesen sind, installieren Sie infra/compose/backup-prod.sh als /usr/local/sbin/rakazo-backup mit dem vom Repository bereitgestellten Timer, damit die Rotation automatisch erfolgt. Ein Backup, das auf demselben Datenträger wie die Datenbank liegt, ist kein Backup; kopieren Sie es daher auf ein anderes System. Testen Sie anschließend die Wiederherstellung einmal auf einem Ersatzserver, bevor Sie darauf angewiesen sind.

Warum es fehlschlägt und was Sie sehen werden

pnpm db:migrate kann die Datenbank nicht erreichen. Die Migration meldet, dass der Datenbankserver unter 127.0.0.1:5433 nicht erreichbar ist. Entweder ist der Postgres-Container nicht gestartet oder er ist zwar gestartet, aber noch nicht bereit. Führen Sie docker compose --env-file .env -f infra/compose/docker-compose.yml ps aus und prüfen Sie, ob der postgres-Dienst als healthy gemeldet wird, da die Compose-Datei eine Health-Check-Prüfung enthält, die alle drei Sekunden ausgeführt wird. Ein Container, der in einer Endlosschleife neu startet, bedeutet meist, dass das pgdata-Volume mit anderen Anmeldedaten erstellt wurde. docker compose ... down -v bereinigt dies, löscht dabei jedoch die Daten.

Der Port ist bereits belegt. Das Starten von Postgres schlägt mit bind: address already in use fehl, wenn ein anderer Prozess Port 5433 belegt; meist ist dies ein früherer Rakazo-Stack, den Sie vergessen haben zu stoppen. sudo ss -lntp | grep 5433 benennt den Prozess.

Ein Bot erhält keinen Computer. Mit SANDBOX_PROVIDER=docker und ohne rakazo/computer:local-Image gibt es nichts, was gestartet werden könnte. docker image ls rakazo/computer beantwortet dies in einer Zeile und pnpm sandbox:build behebt das Problem. Wenn der Supervisor den Docker-Socket nicht erreichen kann, kann er ebenfalls keine Container erstellen; die Fehlermeldung nennt den Pfad: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

Ein langer Befehl bricht mittendrin ab. .env.example setzt SANDBOX_COMMAND_TIMEOUT_MS=300000, wodurch ein einzelner Befehl innerhalb eines Bot-Computers nach fünf Minuten abgebrochen wird. Erhöhen Sie diesen Wert für langsame Builds, anstatt davon auszugehen, dass die Sandbox abgestürzt ist.

pnpm install verursacht verwirrende Fehler. Prüfen Sie vor allem anderen node -v. Der Workspace deklariert >=22, und eine ältere Node-Version schlägt oft innerhalb des Abhängigkeitscodes fehl, anstatt eine klare Meldung über die Version auszugeben.

Die Anmeldung funktioniert lokal, aber nicht über die Domain. BETTER_AUTH_URL, WEB_ORIGIN und API_URL müssen alle denselben öffentlichen Ursprung (Origin) wie die Adresszeile enthalten, einschließlich des Schemas. Ein veralteter http://127.0.0.1:5173-Eintrag in einer dieser Konfigurationen ist die häufigste Ursache dafür, dass eine Sitzung nicht dauerhaft bestehen bleibt.

Aktualisierung eines fixierten Checkouts

Der Upgrade-Pfad in der Dokumentation zum Self-Hosting ist kurz: Laden Sie den neuen Quellcode herunter, führen Sie die Datenbankmigration aus und starten Sie die API sowie den Worker neu.

./scripts/backup.sh
git fetch --all
git checkout NEW_COMMIT_SHA
pnpm install
pnpm --filter @rakazo/db migrate
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

Erstellen Sie zuerst ein Backup. Migrationen verlaufen nur in eine Richtung, und bei einer Beta-Version gibt es keinen verlässlichen Rückweg. Lesen Sie die Commits zwischen Ihrem fixierten SHA und dem neuen Stand, bevor Sie diese übernehmen. Ein so junges Projekt benennt Umgebungsvariablen gelegentlich ohne Vorankündigung um. Eine fehlende Variable führt dazu, dass der Dienst startet und sich unmittelbar danach beendet. Falls Sie noch prüfen, ob Rakazo die richtige Lösung für Sie ist, bietet die Übersicht der selbst gehosteten KI-Agenten einen Vergleich der Alternativen in dieser Kategorie und deren laufende Betriebskosten.

FAQ

Kann ich Rakazo auf einem 1 GB VPS betreiben?

Nein. Postgres, die API, der Worker, der Sandbox-Supervisor und die Web-App laufen gleichzeitig. Mit SANDBOX_PROVIDER=docker fügt jeder aktive Bot einen Container hinzu, der einen grafischen Desktop und einen Browser enthält. Die Dokumentation des Projekts gibt 2 vCPU und 4 GB RAM als ausreichend für API, Worker und Postgres an, sofern E2B das Hosting der Bot-Desktops übernimmt. Betrachten Sie 4 GB als absolutes Minimum für die Control Plane und planen Sie mehr ein, wenn die Desktops auf Ihrem eigenen Server laufen.

Ist der Desktop-Sandbox-Provider auf einem Server sicher?

Nein. desktop führt die Befehle des Bots direkt auf dem Host der API und des Workers aus. Dies geschieht mit den Rechten des Benutzers, der den Prozess ausführt, wodurch dessen Dateien und Anmeldedaten erreichbar sind. Das Repository warnt davor, diesen Modus auf öffentlichen oder gemeinsam genutzten Servern zu verwenden. Nutzen Sie docker für einen Container pro Bot oder e2b, wenn sich mehr als eine Person anmeldet.

Welche Version von Rakazo sollte ich installieren?

Stand 16. August 2026 gibt es ein Tag, v0.1.0-beta, das am 13. August 2026 veröffentlicht und als Pre-Release markiert wurde. Nutzen Sie den Commit, auf den dieses Tag zeigt, 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb, anstatt den Branch main zu verfolgen. Ein Branch kann sich jederzeit ändern und ein Tag kann verschoben werden; daher identifizieren beide keinen eindeutigen Stand, zu dem Sie sicher zurückkehren können. Notieren Sie sich den Commit-Hash, da ein Rollback nur möglich ist, wenn Sie wissen, welche Version zuvor funktionierte.

Wo trage ich meinen OpenRouter API-Key ein?

In .env als OPENROUTER_API_KEY, aber niemals in einer Compose-Datei, die Sie in ein Repository einchecken. Beide Compose-Befehle im Repository übergeben --env-file .env, sodass der Wert die Container erreicht, ohne in die versionierte YAML-Datei geschrieben zu werden. Sie können das Feld auch leer lassen und den Key während des Onboardings direkt in der App eingeben. Setzen Sie beim Anbieter ein Ausgabenlimit für den Key, da ein Bot in einer Endlosschleife das Modell so lange aufruft, bis er manuell gestoppt wird.

Benötige ich einen Domainnamen und TLS?

Für alles, was über einen ersten Test hinausgeht, ja. Die produktive Compose-Datei startet Caddy und bezieht automatisch Zertifikate. Zudem müssen RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN und API_URL denselben öffentlichen HTTPS-Ursprung verwenden. Für einen ersten Testlauf können Sie auf eine Domain verzichten: Führen Sie pnpm dev aus und leiten Sie Port 5173 per SSH weiter, anstatt ihn direkt zu veröffentlichen.