Rakazo selbst hosten: KI-Bot auf dem eigenen VPS

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

Self-Hosting von Rakazo bedeutet, auf einem Linux-Server fünf Komponenten zu betreiben: PostgreSQL, einen Graphile-Worker-Prozess, die API, die Webanwendung und für jeden aktiven Bot jeweils einen Sandbox-Container. 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 seinen eigenen Thread, seinen eigenen Computer, seinen eigenen Speicher und seine eigene Historie. Er kann außerdem Peers oder kurzlebige Subagenten starten.

Dieser letzte Punkt ist der Grund, warum Rakazo auf einen VPS (Virtual Private Server) und nicht auf einen Desktop gehört. Ein Bot, der Speicher hält und geplante Aufgaben ausführt, muss erreichbar sein, während Sie schlafen. Wenn ein Laptop in den Ruhezustand wechselt, wird die Warteschlange unterbrochen.

Rakazo befindet sich im August 2026 noch in einer frühen Betaphase. Betrachten Sie diese Konfiguration daher als funktionsfähigen Aufbau und nicht als fertige Appliance. Der gesamte Stack basiert auf TypeScript: React 19 und Vite für die Webanwendung, Hono für die API, Postgres mit Prisma, Better Auth für Benutzerkonten und Graphile Worker für Hintergrundaufgaben. Graphile Worker speichert seine Warteschlange in Postgres. Deshalb benötigen Sie weder Redis noch einen zweiten Datenspeicher. .env.example setzt WAKEUP_DRIVER=graphile. Das bedeutet, dass das Aufwachen eines Bots durch einen von Postgres unterstützten Job ausgelöst wird. Wenn Sie Postgres stoppen, werden auch alle geplanten Bot-Aktionen beendet. Wenn Sie einen Agenten lieber aus einzelnen Komponenten zusammenstellen möchten, statt das Produkt eines anderen Betreibers auszuführen, ist einen eigenen Agenten aus Komponenten erstellen der andere Weg.

Warum ein 1-GB-Tarif dafür nicht ausreicht

Zählen Sie die Prozesse. Postgres ist einer. Die API ist ein Node-Prozess. Der Worker ist ein zweiter. Die Webanwendung ist ein dritter. Der Sandbox-Supervisor ist ein vierter. Danach erhält jeder laufende Bot einen Container mit einem grafischen Linux-Desktop und einem Browser.

Die Self-Hosting-Dokumentation des Projekts nennt eine realistische Zahl: Eine Maschine mit 2 vCPU und 4 GB reicht für die API, den Worker und Postgres aus, wenn E2B die Bot-Desktops betreibt. Das ist nur die Zahl für die Steuerungsebene, während der rechenintensive Teil an anderer Stelle gehostet wird. Wenn Sie SANDBOX_PROVIDER=docker setzen, werden diese Desktops auf Ihren VPS verschoben. Damit sind 4 GB die Untergrenze und nicht mehr das Ziel. Beginnen Sie mit 8 GB, wenn mehr als ein Bot aktiv bleiben soll, und ermitteln Sie den tatsächlichen Bedarf mit docker stats, während ein Bot arbeitet. Der Browser innerhalb der Sandbox bestimmt den Speicherbedarf maßgeblich. Daher reicht eine Spezifikation auf dem Papier nicht aus. Die allgemeine Methode zur Dimensionierung eines Servers für Agenten beschreibt wie viel RAM und CPU ein Agent-VPS tatsächlich benötigt ausführlich anhand von Messungen.

Eine Einstellung verhindert, dass sich die Situation weiter verschlechtert. .env.example wird mit SANDBOX_IDLE_MS=600000 ausgeliefert. Der Kommentar dazu besagt, dass E2B-Computer beziehungsweise Docker-Computer nach dieser Anzahl inaktiver Millisekunden pausiert oder beendet werden. Nach zehn Minuten Inaktivität wird der Computer entfernt. Der kleinste zulässige Wert ist 30000. Ohne diese Einstellung würde jeder jemals gestartete Bot den Speicher dauerhaft belegen.

Auch der Speicherplatz ist relevant. Das Sandbox-Image, die Node-Module und das Postgres-Volume verwenden denselben Datenträger. Daher sind 40 GB ein sinnvoller Ausgangswert.

Version vor dem Klonen festlegen

Rakazo entwickelt sich schnell weiter, und main ist kein Release. Am 16. August 2026 enthält das Repository genau ein Tag: v0.1.0-beta. Es wurde am 13. August 2026 veröffentlicht und als Prerelease gekennzeichnet.

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

Dieser Commit ist der, auf den v0.1.0-beta verweist. Legen Sie den Commit fest, nicht den Branch oder das Tag. Ein Branch ändert sich beim nächsten git pull unter Ihrer Kontrolle, und ein Tag ist nur eine verschiebbare Bezeichnung, die ein Maintainer auf einen anderen Commit setzen kann. Keines von beiden identifiziert daher einen Quellbaum, zu dem Sie zurückkehren können. Ein Commit-Identifier kann nicht geändert werden. Notieren Sie ihn zusammen mit den anderen Serverdaten, denn wenn ein Upgrade einen Fehler verursacht, besteht die kostengünstige Lösung aus git checkout <old commit> und einem Neuaufbau. Das funktioniert nur, wenn Sie wissen, welcher Commit funktioniert hat.

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 v22 oder höher ausgeben. Das Node-Paket im Ubuntu-Archiv ist normalerweise älter. Installieren Sie Node daher über NodeSource oder nvm. pnpm wird über corepack zusammen mit Node bereitgestellt:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine und das Compose-Plugin decken die übrigen Anforderungen ab. Ihr Benutzer muss außerdem auf den Daemon zugreifen 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 Anmeldeshell. Machen Sie sich vorher klar, welche Berechtigungen das gewährt: Die Mitgliedschaft in docker entspricht root auf dem Rechner, weil jedes Mitglied dieser Gruppe einen Container starten kann, der das Host-Dateisystem einbindet.

.env konfigurieren und anschließend Postgres starten

cp .env.example .env
chmod 600 .env

Zwei Werte müssen geändert werden, bevor irgendein Dienst Netzwerkzugriff erhält. .env.example liefert BETTER_AUTH_SECRET=replace-with-32-plus-character-secret und ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase mit. Rakazo lehnt diese Platzhalterwerte außerhalb der Entwicklung ab. Eine unvollständig konfigurierte Bereitstellung schlägt daher eindeutig fehl, statt mit einem im Repository veröffentlichten Secret zu laufen.

openssl rand -base64 48
openssl rand -hex 32

Starten Sie anschließend ausschließlich die Datenbank 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 Computer-Image des Bots, das in package.json als docker build -t rakazo/computer:local infra/sandboxes/computer definiert ist. Es handelt sich um ein grafisches Image. Der erste Build lädt daher viele Daten herunter und benötigt Zeit. Prüfen Sie mit docker image ls rakazo/computer, ob es vorhanden ist. Der Befehl sollte eine Zeile ausgeben.

Die Compose-Datei veröffentlicht Postgres unter 127.0.0.1:5433:5432. Dieser Port ist ausschließlich über die Loopback-Schnittstelle erreichbar. Lassen Sie diese Einstellung unverändert. Die Anmeldedaten für die Entwicklung lauten rakazo:rakazo und befinden sich im Repository. Ein aus dem Internet erreichbarer Postgres-Port mit einem veröffentlichten Passwort wird innerhalb weniger Stunden von Scannern gefunden. Die Compose-Datei für die Produktion verwendet stattdessen POSTGRES_PASSWORD. Setzen Sie diesen Wert später auf eine zufällige Zeichenfolge.

Der erste Start

pnpm dev

Damit werden vier Komponenten gestartet: die API auf Port 3100, der Graphile Worker, die Vite-Webanwendung auf Port 5173 und der Sandbox-Supervisor auf Port 7091. Die Anwendung ist unter http://127.0.0.1:5173 erreichbar. Dort sollte eine Anmeldeseite angezeigt werden.

Auf einem VPS arbeiten Sie nicht direkt an diesem Rechner. Sie sollten Port 5173 daher nicht veröffentlichen, um auf die Anwendung zuzugreifen. Leiten Sie die Ports stattdessen per SSH (Secure Shell) von Ihrem eigenen Rechner weiter.

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

Beachten Sie den Unterschied zwischen den beiden Ausführungsarten. pnpm dev startet Vite auf dem Host und bindet den Dienst lokal. Der Dienst web in der Compose-Datei veröffentlicht 5173:5173 auf allen Schnittstellen. Wenn Sie den vollständigen Entwicklungs-Compose-Stack auf einem öffentlich erreichbaren VPS starten, ist die Anwendung exponiert. Verwenden Sie daher für alles, was dauerhaft ausgeführt werden soll, die Produktionsdatei und den Reverse Proxy.

Welcher Sandbox-Anbieter ist auf einem Server sicher?

Diese Einstellung muss korrekt gesetzt werden. SANDBOX_PROVIDER in .env akzeptiert vier Werte.

• docker ist der Standardwert. Jeder Bot erhält auf Ihrem Rechner einen eigenen Container, der aus dem erzeugten Image pnpm sandbox:build erstellt wird. Dies ist die schnellste Self-Hosting-Konfiguration.
• e2b führt die Bot-Computer auf E2B aus und benötigt E2B_API_KEY. Das Projekt empfiehlt diese Option für öffentliche oder von mehreren Benutzern verwendete Bereitstellungen, weil die Bot-Computer vom Host getrennt bleiben, auf dem Ihre API und Ihre Datenbank ausgeführt werden.
• desktop führt die Befehle des Bots direkt auf dem API- und Worker-Host aus. Die Anweisung des Repositorys ist eindeutig: Verwenden Sie diese Option nicht auf einem öffentlichen oder gemeinsam genutzten Server.
• fake ist ein Emulator innerhalb des Prozesses für Tests. Er ist nicht für den Produktivbetrieb vorgesehen.

Nehmen Sie diese Warnung zum Desktop-Modus wörtlich. Im Desktop-Modus gibt es überhaupt keine Isolationsgrenze. Der Bot führt Shell-Befehle daher als der Benutzer aus, unter dem der API-Prozess läuft. Er hat Zugriff auf das Home-Verzeichnis dieses Benutzers, dessen SSH-Schlüssel, dessen Cloud-Anmeldedaten und dessen .env. Text auf einer Webseite, die der Bot liest, wird zu einem Befehl auf Ihrem Server. Im Desktop-Modus auf einem Server kann ein Bot in den Besitz Ihrer Zugangsdaten gelangen. Verwenden Sie diesen Modus nur auf einem Rechner, an dem Sie selbst arbeiten, oder gar nicht.

docker bildet eine echte, aber unvollständige Grenze. Ein Bot kann die Dateien eines anderen Bots nicht lesen, weil jeder Bot seinen eigenen Container hat. Der Supervisor, der diese Container erstellt, bindet jedoch /var/run/docker.sock ein. Die Kontrolle über den Docker-Socket des Hosts bedeutet daher Kontrolle über den Host. Halten Sie den Supervisor deshalb privat. .env.example dokumentiert SANDBOX_SUPERVISOR_TOKEN als optionales separates Dienstgeheimnis, das bei einem leeren Wert standardmäßig BETTER_AUTH_SECRET verwendet. Wenn dieses Geheimnis auf seinem Platzhalter belassen wird, ist der Container-erstellende Dienst mit einer Zeichenfolge geschützt, 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 einen Rechner bereit, auf dem sich nichts anderes befindet. Das ist derselbe Grundgedanke wie beim Ausführen von Coding-Agenten in einer kurzlebigen VM: Am günstigsten übersteht ein Agent einen Fehler, wenn sein Rechner keinen Wert hat.

Wohin gehören die Modell-API-Schlüssel?

Rakazo bietet keine verwaltete Abrechnung für Modelle. Sie bringen den Schlüssel selbst mit. .env.example setzt PI_DEFAULT_PROVIDER=openrouter, daher ist OPENROUTER_API_KEY der übliche Speicherort. Schlüssel der Anbieter funktionieren über dieselbe Einstellung.

Bewahren Sie den Schlüssel in .env auf und nicht in einer Datei, die Sie committen. Beide Compose-Befehle im Repository übergeben --env-file .env. Dadurch gelangen die Werte in die Container, ohne jemals in eine von git versionierte YAML-Datei geschrieben zu werden. Sie können OPENROUTER_API_KEY auch leer lassen und während der Ersteinrichtung einen Schlüssel in der Anwendung einfügen. Das ist ein weiterer Grund dafür, dass ENCRYPTION_KEY einen echten Zufallswert und nicht den mitgelieferten Platzhalter enthalten muss.

Legen Sie beim Anbieter ein Ausgabenlimit für den Schlüssel fest, bevor ein Bot ihn verwendet. Ein Bot, der in einer Schleife läuft, verursacht fortlaufende Kosten. Ein Limit pro Schlüssel ist die einzige Begrenzung, die nicht davon abhängt, dass Sie den Verbrauch überwachen. Geben Sie diesem Schlüssel einen eigenen Namen, damit Sie ihn unabhängig widerrufen können.

Vom Entwicklungsmodus zu einem System, das dauerhaft laufen kann

Das Repository enthält eine Compose-Datei für den Produktionsbetrieb. Sie startet Postgres, die API, den Worker, die Webanwendung und Caddy für TLS-Zertifikate (Transport Layer Security), die Caddy automatisch anfordert. 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 die SSH-Anmeldung per Passwort, setzt UFW-Regeln (Uncomplicated Firewall) für SSH, HTTP und HTTPS, aktiviert fail2ban und wendet AppArmor-Profile an. Lesen Sie die Datei, bevor Sie sie ausführen, da sie die Anmeldemethode ändert. Lassen Sie während der Ausführung eine zweite SSH-Sitzung geöffnet.

Die produktive .env benötigt mehr als die Entwicklungsvariante. Die Dokumentation zum Self-Hosting nennt dieses Minimum.

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

Setzen Sie vor dem ersten up einen A-Record auf den Server. Caddy fordert für den in RAKAZO_HOST angegebenen Namen ein Zertifikat an. Die Anforderung schlägt fehl, wenn der Name nicht auf diesen Server aufgelöst wird oder Port 80 von außen nicht erreichbar ist.

Setzen Sie außerdem SIGNUP_ALLOWLIST=you@example.com. SIGNUPS_ENABLED=true ist der Standardwert. Eine Instanz unter einem öffentlichen Namen nimmt daher Registrierungen von jeder Person an, die sie findet, und jedes neue Konto erhält einen Computer. Verwenden Sie zunächst eine Allowlist. Sie können diese Einschränkung später lockern.

Behandeln Sie docs/self-host.md im Repository als maßgebliche Quelle für die Produktionseinstellungen. Diese Datei wird zusammen mit dem Code geändert, dieser Leitfaden jedoch nicht. Da Compose die eigentliche Arbeit übernimmt, gelten die üblichen Regeln. Die Docker-Compose-Grundlagen für einen VPS erklären, warum --env-file und benannte Volumes wichtiger werden, sobald ein Stack monatelang unbeaufsichtigt laufen soll.

Backups

Postgres und das Verzeichnis data/ bilden die vollständige Instanz.

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

backup.sh erstellt einen Dump von Postgres und archiviert data/. Für einen Rechner, auf den 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 auf derselben Festplatte wie die Datenbank ist kein Backup. Kopieren Sie es daher auf ein anderes System. Stellen Sie es anschließend einmal auf einem Ersatzserver wieder her, bevor Sie es benötigen.

Warum es fehlschlägt und was Sie sehen

pnpm db:migrate kann die Datenbank nicht erreichen. Die Migration meldet, dass sie den Datenbankserver unter 127.0.0.1:5433 nicht erreichen kann. Entweder läuft der Postgres-Container nicht, oder er läuft und ist 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 fehlerfrei gemeldet wird, da die Compose-Datei für ihn eine Gesundheitsprüfung enthält, die alle drei Sekunden ausgeführt wird. Ein Container, der ständig neu startet, weist meist darauf hin, dass das Volume pgdata mit anderen Zugangsdaten erstellt wurde. docker compose ... down -v entfernt es und löscht damit auch die Daten.

Der Port ist bereits belegt. Der Start von Postgres schlägt mit bind: address already in use fehl, wenn ein anderer Prozess Port 5433 belegt. Meist läuft noch ein älterer Rakazo-Stack, den Sie nicht beendet haben. sudo ss -lntp | grep 5433 zeigt, welcher Prozess den Port verwendet.

Ein Bot erhält nie einen Computer. Wenn SANDBOX_PROVIDER=docker ohne rakazo/computer:local-Image ausgeführt wird, gibt es nichts zu starten. docker image ls rakazo/computer beantwortet die Ursache in einer Zeile, und pnpm sandbox:build behebt sie. Wenn der Supervisor den Docker-Socket nicht erreichen kann, kann er ebenfalls keine Container erstellen. Die Meldung 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, sodass ein einzelner Befehl im Computer eines Bots nach fünf Minuten abgebrochen wird. Erhöhen Sie diesen Wert für langsame Builds, statt von einem Absturz der Sandbox auszugehen.

pnpm install funktioniert auf verwirrende Weise nicht. Prüfen Sie zuerst node -v. Der Workspace setzt >=22 voraus, und eine ältere Node-Version schlägt im Abhängigkeitscode fehl, statt eine Versionsmeldung auszugeben.

Die Anmeldung funktioniert lokal, aber nicht über die Domain. BETTER_AUTH_URL, WEB_ORIGIN und API_URL müssen alle denselben öffentlichen Ursprung wie die Adressleiste verwenden, einschließlich des Schemas. Ein veraltetes http://127.0.0.1:5173 in einer dieser Einstellungen ist meist die Ursache dafür, dass die Sitzung nicht bestehen bleibt.

Aktualisieren eines fest auf einen Commit gesetzten Checkouts

Der Upgrade-Pfad in der Dokumentation zum Self-Hosting ist kurz: Rufen Sie den neuen Quellcode ab, 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 werden vorwärts ausgeführt, und bei einer Beta gibt es keinen verlässlichen Rückweg. Lesen Sie die Commits zwischen dem festgelegten SHA und dem neuen SHA, bevor Sie sie übernehmen. Bei einem so jungen Projekt werden Umgebungsvariablen möglicherweise ohne Ankündigung umbenannt. Eine fehlende Variable zeigt sich dann als Dienst, der startet und anschließend beendet wird. Wenn Sie noch entscheiden, ob Rakazo überhaupt für den Betrieb geeignet ist, behandelt die Übersicht selbst gehosteter KI-Agenten, welche anderen Lösungen in diese Kategorie fallen und welche laufenden Kosten jeweils anfallen.

FAQ

Kann ich Rakazo auf einem 1-GB-VPS ausführen?

Nein. Postgres, die API, der Worker, der Sandbox-Supervisor und die Webanwendung laufen gleichzeitig. Mit SANDBOX_PROVIDER=docker fügt jeder aktive Bot außerdem einen Container mit grafischer Desktop-Umgebung und Browser hinzu. Die projek eigenen Dokumentation nennt 2 vCPU und 4 GB nur dann als ausreichend für API, Worker und Postgres, wenn E2B die Bot-Desktops hostet. Betrachten Sie 4 GB als Mindestgröße für die Steuerungsebene. Wenn die Desktops auf Ihrem Rechner laufen, benötigen Sie mehr.

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

Nein. desktop führt die Befehle des Bots direkt auf dem Host der API und des Workers aus. Dabei verwendet es den Benutzer, unter dem der Prozess läuft, und kann auf dessen Dateien und Anmeldedaten zugreifen. Das Repository weist darauf hin, dass Sie es nicht auf einem öffentlichen oder gemeinsam genutzten Server verwenden sollen. Verwenden Sie docker für einen Container pro Bot oder e2b, wenn sich mehr als eine Person anmeldet.

Welche Version von Rakazo sollte ich installieren?

Am 16. August 2026 gibt es ein Tag: v0.1.0-beta. Es wurde am 13. August 2026 veröffentlicht und als Vorabversion gekennzeichnet. Checken Sie den Commit aus, auf den es verweist: 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb. Verwenden Sie nicht fortlaufend main. Ein Branch kann sich ändern, und ein Tag kann auf einen anderen Commit gesetzt werden. Daher bezeichnet keines von beiden eindeutig einen Quellbaum, zu dem Sie zurückkehren können. Dokumentieren Sie den Commit. Ein Rollback ist nur möglich, wenn Sie wissen, welcher Commit funktioniert hat.

Wo muss ich meinen OpenRouter-API-Key hinterlegen?

In .env als OPENROUTER_API_KEY. Legen Sie ihn niemals in einer Compose-Datei ab, die Sie committen. Beide Compose-Befehle im Repository übergeben --env-file .env. Dadurch erreicht der Wert die Container, ohne in versionierten YAML-Dateien gespeichert zu werden. Sie können das Feld auch leer lassen und den Key während des Onboardings in der Anwendung eingeben. Legen Sie beim Anbieter ein Ausgabenlimit für den Key fest. Ein Bot in einer Endlosschleife ruft das Modell weiter auf, bis etwas ihn stoppt.

Benötige ich einen Domainnamen und TLS?

Für alles, was über einen ersten Test hinausgeht, ja. Die Compose-Datei für den Produktivbetrieb startet Caddy und bezieht Zertifikate automatisch. RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN und API_URL müssen dieselbe öffentliche HTTPS-Origin enthalten. Für einen ersten Test können Sie die Domain weglassen. Führen Sie pnpm dev aus und leiten Sie Port 5173 per SSH weiter, statt ihn zu veröffentlichen.