KiroCrew auf dem VPS selbst hosten und dauerhaft ausführen

Warum KiroCrew auf einem VPS statt auf einem Laptop selbst hosten

KiroCrew selbst zu hosten lohnt sich nur auf einem Rechner, der nie in den Ruhezustand wechselt. Deshalb ist ein VPS der richtige Betriebsort, ein Laptop dagegen nicht. KiroCrew speichert Sitzungsverläufe, semantischen Speicher, geplante Jobs und die Freigabewarteschlange auf der Festplatte. Beim Neustart des Prozesses lädt es diese Daten wieder. Das hilft nicht, wenn der Prozess um 03:00 bei Fälligkeit eines geplanten Jobs nicht läuft. Ein geschlossener Laptop führt den Prozess nicht aus.

KiroCrew ist ein Open-Source-Agent-Arbeitsbereich des Kiro-Teams. Die Lizenz ist Apache 2.0. Die ersten öffentlichen Releases erschienen Anfang August 2026. Ein Prozess namens Gateway verwaltet den Zustand und stellt ein Web-Dashboard auf Port 5476 bereit. Sie erreichen dieses Gateway über das Dashboard, über die kirocrew CLI oder über einen Chat-Kanal wie Slack. Das Gateway ist der einzige Bestandteil, den Sie selbst hosten. In diesem Leitfaden geht es daher darum, es dauerhaft auszuführen, vom öffentlichen Internet fernzuhalten und nach einem fehlerhaften Upgrade wiederherstellen zu können.

Vor dem Start sind zwei Punkte wichtig. KiroCrew verwendet kiro-cli. Dafür ist eine einmalige Anmeldung mit einem Kiro-Konto erforderlich. Die Agent-Inferenz wird über einen Kiro-Tarif abgerechnet. Stand August 2026 ist dies daher keine Offline-Konfiguration. Außerdem ist das Projekt erst wenige Wochen alt. Gehen Sie davon aus, dass Sie irgendwann ein Rollback benötigen, und installieren Sie es so, dass dies möglich ist. Wenn Sie noch keinen Agent auf einem Server ausgeführt haben, erklärt einen Coding-Agent auf einem VPS auszuführen die Grundlagen, auf denen dieser Leitfaden aufbaut. Wenn die Agent-Seite für Sie weniger vertraut ist als die Serverseite, sollten Sie zuerst verstehen, was eine Agent-Schleife, ihre Tools und ihr Speicher tatsächlich sind. Dann wirken die folgenden Entscheidungen wie begründete Konfigurationen und nicht wie undurchsichtige Befehlsfolgen.

Was KiroCrew benötigt und wo sein Zustand gespeichert wird

Eine native Installation benötigt Python 3.10 oder neuer. Das Projekt empfiehlt 3.12. Wenn Sie das Dashboard aus dem Quellcode erstellen, benötigen Sie außerdem Node.js 18 oder neuer sowie kiro-cli. kiro-cli wird beim ersten Start installiert und meldet Sie automatisch an. Bei der Container-Installation benötigen Sie diese Komponenten nicht auf dem Host. Sie benötigen Docker. Das ist der wichtigste Grund, diese Variante zu bevorzugen.

Der Zustand wird in ~/.kiro/crew gespeichert. Mit der Umgebungsvariablen KIROCREW_HOME können Sie ihn an einem anderen Ort speichern. Darin befinden sich:

• config.json: Gateway-Einstellungen und Zugangsdaten für Chat-Kanäle.
• .env: Secrets.
• workspace/memory/: Einstellungen, Projektnotizen und Chatverlauf.
• memory.db und memory_index.db: die semantischen und Volltextindizes.
• models/: das Embedding-Modell, das beim ersten Start heruntergeladen wird.
• gateway.log und security_events.jsonl: das Laufzeitprotokoll und das Protokoll der Sicherheitsereignisse.

Dieses Verzeichnis ist die Installation. Kopieren Sie es auf einen neuen VPS, und Sie haben Ihren Agenten umgezogen. Deshalb ist der folgende Abschnitt zu Backups wichtiger als der Abschnitt zur Installation.

Planen Sie den Speicherplatzbedarf und nicht nur den RAM-Bedarf. Das Gateway ist ein Python-Prozess. Die eigentliche Last auf dem System entsteht durch das, was der Agent ausführt, beispielsweise einen Build oder eine Testsuite. Das Zustandsverzeichnis wächst mit dem Chatverlauf. Das Embedding-Modell wird beim ersten Start heruntergeladen. Messen Sie den tatsächlichen Bedarf daher nach einigen Wochen mit du -sh ~/.kiro/crew auf Ihrem eigenen System, statt einer Zahl zu vertrauen, die im ersten Monat eines Projekts veröffentlicht wurde. Im Gegensatz dazu gibt eine Laufzeit jedem Worker einen eigenen Container und einen eigenen Browser. Bei Self-Hosting der KI-Mitarbeiter von OpenBot ist daher zuerst der RAM-Bedarf entscheidend und erst danach der Speicherplatz.

Welchen der drei Installationspfade sollten Sie verwenden?

Das Projekt veröffentlicht drei Varianten. Das Installationsskript in einer Zeile lädt ein Wheel herunter und legt kirocrew in Ihrem PATH ab:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Es akzeptiert ein Channel-Flag und ein Versions-Flag:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

Das Container-Image wird unter ghcr.io/kirodotdev/kirocrew veröffentlicht, für linux/amd64 und linux/arm64 unter jedem Tag. Der Build aus dem Quellcode erfordert git clone und make build. Er ist für Personen gedacht, die den Code ändern, nicht für Personen, die ihn ausführen.

Verwenden Sie den Container. Bei einer nativen Installation liegen Python-Pakete, Node und kiro-cli auf demselben Host wie Ihre anderen Dienste. Wenn ein Upgrade fehlschlägt, müssen Sie die Änderungen manuell zurücknehmen. Der Container hält die Laufzeitumgebung in einem Image und den Zustand in einem Volume. Dadurch besteht ein Rollback aus dem Ändern des Tags und einem Neustart.

Binden Sie das Image an einen Release-Tag, nicht an stable

Das Beispiel des Projekts selbst verwendet den Tag stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

stable ist ein beweglicher Tag. Er zeigt jeweils auf den neuesten stabilen Release. Dadurch kann der nächste Pull die ausgeführte Version ändern, ohne dass Sie dies festlegen. Außerdem lässt sich am Tag nicht erkennen, welche Version zuvor verwendet wurde. Versionstags sind unveränderlich. Verwenden Sie daher einen solchen Tag. Der neueste Release vom 6. August 2026 ist 0.1.3. Er wurde am 5. August 2026 veröffentlicht. Es gibt außerdem den Tag nightly. Bei einem so jungen Projekt bedeutet das, dass sich der Code möglicherweise heute Morgen geändert hat.

Schreiben Sie /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

Starten Sie den Container. Prüfen Sie anschließend den Health-Endpunkt, den das Image auch für sein eigenes HEALTHCHECK verwendet:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

docker compose ps sollte den Container innerhalb von etwa einer Minute als gesund melden. /api/health antwortet ohne Token. Das gilt auch für /api/live und /api/ready. Dadurch können diese Endpunkte als Probes verwendet werden. Wenn der Status bei starting bleibt, lesen Sie zuerst docker logs kirocrew, bevor Sie etwas ändern. Beim ersten Start wird das Embedding-Modell heruntergeladen. Eine langsame Verbindung kann den ersten Start daher deutlich verlängern.

Mit systemd dauerhaft ausführen

restart: unless-stopped startet den Container nach einem Absturz und nach einem Reboot erneut, sofern Docker selbst beim Booten gestartet wird. Eine Unit-Datei macht diese Abhängigkeit explizit und stellt einen einzelnen Befehl bereit, mit dem Sie den gesamten Stack vor einem Backup stoppen. Einen Docker-Compose-Stack beim Booten starten beschreibt das allgemeine Vorgehen. Für KiroCrew sieht das in /etc/systemd/system/kirocrew.service so aus:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

systemctl status kirocrew sollte active (exited) anzeigen. Das ist das erwartete Ergebnis für diese Unit. Type=oneshot mit RemainAfterExit=yes ist hier korrekt, weil docker compose up -d zurückkehrt, sobald der Container gestartet wurde: systemd überwacht, dass der Stack läuft, nicht einen Prozess im Vordergrund. Verwenden Sie stattdessen Type=simple, sieht systemd, dass der Befehl sofort beendet wird, markiert den Dienst als beendet und gibt entweder auf oder startet ihn abhängig von Ihrer Einstellung Restart= in einer Neustartschleife. Bei einer nativen Installation stellt das Projekt mit kirocrew service install ein eigenes Gegenstück bereit. Es schreibt /etc/systemd/system/kirocrew.service und führt das Gateway unter Ihrem Benutzerkonto aus. Führen Sie nicht beide Units aus. Die ausführlichere Variante dieses Themas finden Sie unter systemd-Dienste und Timer auf einem VPS. Eine Unit, die nicht erneut gestartet wird, bleibt unbemerkt, sofern Sie sie nicht Meldungen ausgeben lassen. Fügen Sie daher einen OnFailure=-Handler hinzu, der eine Warnung an Ihren eigenen ntfy-Server sendet. Dann erfahren Sie über Ihr Smartphone, dass das Gateway nicht läuft, statt durch einen geplanten Job, der nie ausgeführt wurde.

Erster Start: Anmelden und ein Dashboard-Token erstellen

Der Container startet das Gateway, aber die Agent-Laufzeit ist noch nicht angemeldet. Melden Sie sich im Container an:

docker exec -it kirocrew kiro-cli login

Dabei werden ein Gerätecode und eine URL ausgegeben. Öffnen Sie die URL in Ihrem eigenen Browser. Erstellen Sie anschließend ein Dashboard-Token:

docker exec kirocrew kirocrew token --ttl 2h

Die Dashboard-URL lautet http://localhost:5476/?token=<the token>. Tokens laufen ab: Sitzungen sind standardmäßig eine Stunde gültig, und das dokumentierte Maximum beträgt zwanzig Stunden. Wenn ein Dashboard leer geladen wird oder Sie direkt wieder zur Anmeldung zurückgeleitet werden, ist meist das Token abgelaufen. Erstellen Sie dann ein neues Token. Fügen Sie ein Token niemals in ein Ticket oder eine Chatnachricht ein. Wer das Token besitzt, kann Ihren Agenten verwenden.

Das Dashboard über SSH erreichen und Port 5476 niemals veröffentlichen

Sehen Sie sich die Bind-Adresse im Beispiel des Projekts noch einmal an: -p 127.0.0.1:5476:5476. Innerhalb des Containers lauscht das Gateway auf 0.0.0.0, weil es über das Port-Mapping erreichbar sein muss. Das Mapping selbst veröffentlicht den Port jedoch nur auf Loopback des Hosts. Entfernen Sie das Präfix 127.0.0.1:, ist das Gateway für jeden im öffentlichen Internet erreichbar, der diesen Port scannt. Eine Firewall-Regel schützt Sie ebenfalls nicht: Docker veröffentlicht Ports, indem es DNAT-Regeln schreibt, die vor der Filterung durch ufw ausgewertet werden. Daher hat ufw deny 5476 keine Wirkung auf einen veröffentlichten Port. Docker-Ports umgehen ufw erklärt diesen Mechanismus.

Leiten Sie den Port stattdessen von Ihrem Laptop per SSH weiter:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

Lassen Sie diesen Befehl laufen und öffnen Sie lokal http://localhost:5476/?token=<the token>. Damit die Weiterleitung bei jeder Verbindung automatisch eingerichtet wird, tragen Sie sie in ~/.ssh/config ein:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

Wenn Port 5476 auf Ihrem Laptop bereits verwendet wird, ändern Sie nur die Zahl auf der linken Seite: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com. Öffnen Sie anschließend http://localhost:45476/?token=.... Sobald ein zweiter Agent denselben Rechner verwendet, werden Sie solche Weiterleitungen stapeln, weil open-kritt für Sicherheitsscans selbst hosten ein weiteres Dashboard erzeugt, das nur auf Loopback lauscht, auf demselben Server und auf Port 5173.

Bei der Verwendung eines Tunnels müssen Sie mit folgendem dokumentierten Verhalten rechnen: Das Gateway behandelt weitergeleitete Anfragen als remote. Deshalb verweigern die Endpunkte für Konfigurationsänderungen und die Anzeige von Secrets diese Anfragen im Dashboard. Wenn sich eine Einstellung über SSH nicht speichern lässt, ist das erwartetes Verhalten und kein Fehler. Bearbeiten Sie die Konfiguration stattdessen direkt auf dem Host:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

Für den Zugriff per Smartphone verweist das Projekt auf tailscale serve von Tailscale. Dadurch bleibt das Dashboard in Ihrem eigenen Tailnet und ist nicht unter einem öffentlichen Hostnamen erreichbar. Bevorzugen Sie diese Lösung gegenüber einem öffentlichen Reverse Proxy. Das Token wird in der URL übertragen. Eine URL wird auf ihrem gesamten Weg in jedes Access-Log geschrieben. Diese Regel bezieht sich darauf, was hinter dem Port läuft, nicht auf den Port selbst: Etwas wie Halcyon, das eine Jellyfin-Bibliothek als durchsuchbaren Videoladen der 90er neu erstellt ist für den Zugriff durch andere Personen vorgesehen und eignet sich daher für einen Reverse Proxy. Ein Gateway, das Befehle auf Ihrem Server ausführen kann, dagegen nicht.

Geben Sie dem Agenten den kleinstmöglichen Wirkungsbereich

Der Container prüft beim ersten Start, ob Sandbox-Unterstützung verfügbar ist. Das Ergebnis entscheidet, ob Agenten Befehle ausführen dürfen. Ist die Isolation von Namespaces verfügbar, laufen die Subprozesse des Agenten isoliert. Ist sie nicht verfügbar und KIROCREW_ALLOW_UNSANDBOXED=1 nicht gesetzt, wird die Ausführung verweigert, statt sie ohne Isolation fortzusetzen. Ein Gateway, das gesund wirkt, während jede Aufgabe hängen bleibt, hat meist genau dieses Problem. Die Entscheidung steht nach dem ersten Lauf in docker logs kirocrew. Das Projekt stellt außerdem ein seccomp-Profil (secure computing mode) bereit, das Sie anwenden können:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json

    security_opt:
      - seccomp:./kirocrew-seccomp.json

Wenn Sie KIROCREW_ALLOW_UNSANDBOXED=1 setzen, muss klar sein, was sich dadurch ändert: Der Container ist dann die einzige Grenze zwischen dem Agenten und Ihrem Server. Die Warnung des Projekts sollte vollständig wiederholt werden. Binden Sie keine Hostpfade ein, die Sie dem Agenten nicht direkt übergeben würden. In der Praxis sind damit der Docker-Socket, jeder Bind-Mount von / und jedes Verzeichnis ausgeschlossen, das die Daten eines anderen Dienstes enthält.

Der restliche Rahmen gilt für jeden Agenten, der Befehle ausführen darf. Beschränken Sie seine Zugangsdaten auf das eine Repository oder den einen Bucket, den er benötigt. Verwenden Sie niemals ein persönliches Token mit kontoweiten Berechtigungen. Lassen Sie den Agenten unter einem dedizierten Benutzer laufen, dessen Home-Verzeichnis keine anderen Daten enthält. Genau dafür sind Benutzer mit geringstmöglichen Berechtigungen auf einem VPS gedacht. Wenn der Agent Code schreibt und diesen anschließend ausführt, geben Sie ihm eine Maschine, die er beschädigen darf. Eine temporäre VM für Coding-Agenten bildet eine stärkere Grenze als jedes Flag in dieser Compose-Datei, weil Sie die VM löschen können, statt sie zu bereinigen. Derselbe Grundsatz gilt für OpenClaw sicher auf einem VPS ausführen und den Hermes-Agenten auf einem VPS selbst hosten. Auch Tools vergrößern den Wirkungsbereich: Wenn Sie dem Agenten die Websuche überlassen, wird jede von ihm abgerufene Seite zu nicht vertrauenswürdiger Eingabe. Ihn auf Ihre eigene SearXNG-Instanz verweisen ist daher ebenso eine Entscheidung zur Prompt-Injection-Abwehr wie eine Konfigurationsentscheidung. Geplante Aufgaben verursachen außerdem Kosten, während Sie schlafen, da die Inferenz Ihrem Kiro-Tarif berechnet wird. Legen Sie deshalb die unter die Kosten eines AI-Agenten auf einem VPS begrenzen beschriebenen Limits fest, bevor Sie einen nächtlichen Job hinzufügen.

Das Statusvolume vor jedem Upgrade sichern

Ermitteln Sie zuerst den tatsächlichen Volumenamen. Compose versieht benannte Volumes mit dem Projektnamen. Standardmäßig entspricht dieser dem Verzeichnisnamen. Das in /opt/kirocrew/compose.yaml als kirocrew-home deklarierte Volume wird daher als kirocrew_kirocrew-home angelegt:

docker volume ls

Stoppen Sie das Gateway, bevor Sie etwas kopieren. memory.db und memory_index.db sind SQLite-Datenbanken. Wird eine Datenbank während eines Schreibvorgangs kopiert, kann die Kopie eine unvollständig geschriebene Transaktion enthalten. Beim Wiederherstellen wird daraus eine beschädigte Datei. Die Migrationanleitung des Projekts schreibt dasselbe vor: Verschieben Sie den Speicher nur, wenn die Gateways gestoppt sind. Diese Regel gilt nicht nur für KiroCrew. Wenn auf dem Server zusätzlich ein Fotoserver läuft, enthält der Vergleich von PhotoPrism und Immich die genauen Sicherungsbefehle für beide Anwendungen.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

Kopieren Sie das Archiv vom Server auf ein anderes System. Zum Wiederherstellen verwenden Sie denselben Befehl, wenn der Container gestoppt ist, und ersetzen tar czf durch tar xzf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

Der Umzug auf einen neuen Host unterscheidet sich von einer Wiederherstellung am bestehenden Host. Das Projekt beschreibt diesen Vorgang ausdrücklich. Der Chatverlauf und die Projektnotizen unter workspace/memory/ werden übernommen. Das gilt auch für die beiden Datenbankdateien und config.json. PID-Dateien, das Sicherheitsereignisprotokoll und .env sind an den alten Host gebunden. Übernehmen Sie diese Dateien daher nicht und geben Sie die Secrets auf dem neuen Server erneut ein.

Wie führen Sie ein fehlerhaftes Upgrade zurück

Das Upgrade ist kurz und nur deshalb sicher, weil Sie eine Version festgelegt haben. Erstellen Sie zuerst das Backup und ändern Sie dann den Tag:

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

docker compose up -d lädt das Image, falls es noch nicht auf dem Server vorhanden ist. Daher besteht das gesamte Upgrade aus der Änderung des Tags. Das Rollback erfolgt mit derselben Abfolge und der alten Versionsnummer. Sie erhalten damit genau das Image, das zuvor verwendet wurde, weil Versionstags unveränderlich sind.

Das Zurücksetzen der Binärdatei funktioniert sauber. Beim Zustand kann es jedoch Probleme geben. Ein neueres Gateway kann config.json neu schreiben oder die In-Memory-Datenbanken in eine Form migrieren, die ein älteres Gateway nicht lesen kann. Stand August 2026 ist kein Downgrade-Pfad dokumentiert. Wenn das ältere Image startet und sich anschließend ungewöhnlich verhält, sollten Sie dies nicht untersuchen. Stoppen Sie es, stellen Sie das vor dem Upgrade erstellte Backup wieder her und starten Sie erneut. Genau deshalb wird das Backup zuerst erstellt. Bei einem noch so jungen Projekt funktioniert die Gewohnheit, jetzt zu aktualisieren und erst später ein Backup zu erstellen, nicht.

Was hier nicht bewiesen ist

Seien Sie sich über das Alter dieser Software im Klaren. Die Version 0.1.3 ist zum Zeitpunkt der Erstellung dieses Textes erst wenige Tage alt. Ihre Release Notes bestehen aus automatisierten Changelog-Links und nicht aus Migrationshinweisen. Außerdem gibt es noch keine Erfahrungen mit Upgrades. Nichts in dieser Anleitung ist ein langfristiges Ergebnis. Betrachten Sie das Wachstum des Arbeitsspeichers, die Datenbankgröße und die Zuverlässigkeit des Schedulers daher als Werte, die Sie auf Ihrem eigenen System messen müssen, und nicht als Eigenschaften, die Sie voraussetzen können.

Zwei Verhaltensweisen sollten Sie selbst testen, bevor Sie sich darauf verlassen. Prüfen Sie erstens, ob ein Downgrade Zustände liest, die von einer neueren Version geschrieben wurden. Testen Sie das an einer Kopie des Volumes, solange ein Fehler keine Auswirkungen hat, und nicht während eines Ausfalls. Prüfen Sie zweitens, wie sich das Gateway verhält, wenn die Kiro-Anmeldung abläuft, während ein geplanter Job fällig ist. Beide Punkte können bei einem jungen Projekt problematisch sein und zwischen Releases unauffällig behoben werden. Beide lassen sich jetzt mit geringem Aufwand prüfen.

FAQ

Warum wird das KiroCrew-Dashboard nicht unter der öffentlichen IP-Adresse meines Servers geöffnet?

Weil das veröffentlichte Beispiel den Port an Loopback bindet. -p 127.0.0.1:5476:5476 ordnet den Port des Containers ausschließlich der Loopback-Adresse des Hosts zu. Das ist beabsichtigt. Greifen Sie darauf zu, indem Sie den Port mit ssh -N -L 5476:127.0.0.1:5476 you@your-server über SSH weiterleiten. Öffnen Sie anschließend http://localhost:5476/?token=<token> auf Ihrem Laptop. Wenn Sie das Präfix 127.0.0.1: entfernen, ist das Gateway im öffentlichen Internet erreichbar. Eine Firewall-Regel kann den Zugriff dann nicht ausreichend einschränken, weil die von Docker veröffentlichten DNAT-Regeln für Ports ausgewertet werden, bevor ufw den Datenverkehr filtert.

Wo speichert KiroCrew seine Daten, und was sollte ich sichern?

Alle Daten liegen unter ~/.kiro/crew. Innerhalb des Container-Images entspricht dieser Pfad /home/kirocrew/.kiro/crew. Mit KIROCREW_HOME lässt sich der Pfad verlagern. Sichern Sie das gesamte Verzeichnis oder das gesamte Docker-Volume, während das Gateway gestoppt ist. Bei memory.db und memory_index.db handelt es sich um SQLite-Datenbanken. Eine Kopie, die während eines Schreibvorgangs des Gateways erstellt wird, kann daher inkonsistent sein. Beim Umzug auf einen neuen Host übernehmen Sie workspace/memory/, die beiden Datenbankdateien und config.json. PID-Dateien, das Sicherheitsereignisprotokoll und .env gehören dagegen zum alten Host.

Sollte ich das Tag stable oder ein Versions-Tag verwenden?

Verwenden Sie ein Versions-Tag. stable ändert sich bei jeder neuen Version. Dadurch kann sich die ausgeführte Version beim nächsten Pull unbemerkt ändern. Außerdem lässt das Tag selbst nicht erkennen, welche Version ausgeführt wird. Versions-Tags wie 0.1.3 sind unveränderlich. Genau dadurch funktionieren Rollbacks: Sie tragen die alte Versionsnummer wieder ein und erhalten dasselbe Image. Am 6. August 2026 ist 0.1.3 die neueste Version.

Warum weigert sich mein Agent, Befehle auszuführen?

Der Container prüft beim ersten Start, ob Sandbox-Unterstützung verfügbar ist. Wenn er Agent-Unterprozesse nicht isolieren kann und KIROCREW_ALLOW_UNSANDBOXED=1 nicht gesetzt ist, führt er sie nicht ungeschützt aus. Stattdessen verweigert er die Ausführung. Dadurch wirkt das Gateway betriebsbereit, während jede Aufgabe hängen bleibt. docker logs kirocrew zeigt die beim ersten Start getroffene Sandbox-Entscheidung an. Wenn Sie die Variable setzen, ist der Container die einzige Grenze zwischen dem Agenten und dem Host. Binden Sie in diesem Fall nichts ein, was Sie dem Agenten nicht direkt übergeben würden.

Benötige ich ein Kiro-Konto, um KiroCrew selbst zu hosten?

Ja, Stand August 2026. KiroCrew ist freie Software unter der Apache-2.0-Lizenz. Es steuert jedoch kiro-cli, wofür eine einmalige Anmeldung erforderlich ist. Die Inferenz des Agenten wird über einen Kiro-Tarif abgerechnet. Führen Sie im Container docker exec -it kirocrew kiro-cli login aus und bestätigen Sie den Gerätecode in Ihrem Browser. Bis diese Anmeldung abgeschlossen ist, startet das Gateway und das Dashboard wird geladen. Der Agent hat jedoch kein Modell, mit dem er kommunizieren kann.