KiroCrew auf dem VPS selbst hosten und dauerhaft ausführen

Warum Sie 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. Ein VPS ist deshalb der passende Ort, ein Laptop nicht. KiroCrew speichert Sitzungsverläufe, semantischen Speicher, geplante Jobs und die Genehmigungswarteschlange 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-Agentenarbeitsbereich des Kiro-Teams. Er steht unter der Apache-2.0-Lizenz. Die ersten öffentlichen Releases erschienen Anfang August 2026. Ein als Gateway bezeichneter Prozess verwaltet den Zustand und stellt ein Web-Dashboard auf Port 5476 bereit. Sie greifen über das Dashboard, über die kirocrew CLI oder über einen Chat-Kanal wie Slack auf dieses Gateway zu. Sie hosten nur das Gateway selbst. 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 müssen Sie zwei Dinge wissen. KiroCrew steuert kiro-cli. Dafür ist eine einmalige Anmeldung mit einem Kiro-Konto erforderlich. Die Agenteninferenz wird über einen Kiro-Tarif abgerechnet. Daher handelt es sich im Oktober 2026 nicht um eine Offline-Konfiguration. Das Projekt ist außerdem noch jung und entwickelt sich schnell: Das neueste stabile Release wechselte von 0.1.3 am 5. August 2026 zu 0.8.0 am 9. Oktober 2026. Gehen Sie davon aus, dass Sie irgendwann ein Rollback durchführen müssen, und installieren Sie KiroCrew so, dass dies möglich ist. Wenn Sie bisher noch keinen Agenten auf einem Server ausgeführt haben, behandelt einen Coding-Agenten auf einem VPS ausführen die Grundlagen, auf denen dieser Leitfaden aufbaut. Wenn die Agentenseite für Sie neuer ist als die Serverseite, sollten Sie zuerst verstehen, was eine Agentenschleife, ihre Tools und ihr Speicher tatsächlich sind. Dann wirken die folgenden Entscheidungen wie nachvollziehbare Konfigurationsentscheidungen und nicht wie undurchsichtige Befehle.

Was KiroCrew benötigt und wo sein Zustand gespeichert wird

Für eine native Installation benötigen Sie Python 3.12 oder neuer sowie Node.js 22.12.0 oder neuer, wenn Sie das Dashboard aus dem Quellcode erstellen. Das Projekt empfiehlt Node 24 LTS. Außerdem benötigen Sie kiro-cli, das Sie nach der zugehörigen Dokumentation installieren und sich mit kiro-cli login anmelden. Für die Container-Installation benötigen Sie davon nichts auf dem Host. Sie benötigt Docker. Das ist der wichtigste Grund, sie zu bevorzugen.

Der Zustand wird in ~/.kiro/crew gespeichert. Mit der Umgebungsvariable KIROCREW_HOME können Sie ihn an einen anderen Speicherort verschieben. Der Inhalt umfasst:

• config.json: Gateway-Einstellungen und Zugangsdaten für Chat-Kanäle.
• .env: Geheimnisse.
• workspace/memory/: Einstellungen, Projektnotizen und Chatverlauf.
• memory.db und memory_index.db: semantische und Volltextindizes.
• models/: das Einbettungsmodell, das beim ersten Start heruntergeladen wird.
• security_events.jsonl: das Sicherheitsereignisprotokoll.

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

Planen Sie eher den Speicherplatz als den Arbeitsspeicher. 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 Einbettungsmodell wird beim ersten Start heruntergeladen. Messen Sie daher nach einigen Wochen mit du -sh ~/.kiro/crew auf Ihrem eigenen System, statt einer Angabe zu vertrauen, die in den ersten Monaten eines Projekts veröffentlicht wurde. Im Gegensatz dazu gibt eine Laufzeit jedem Worker einen eigenen Container und einen eigenen Browser. Beim Self-Hosting der KI-Mitarbeiter von OpenBot ist daher zunächst der Arbeitsspeicher und nicht der Speicherplatz die entscheidende Größe.

Welchen der drei Installationspfade sollten Sie verwenden

Das Projekt veröffentlicht drei Varianten. Das Installationsskript mit einer Zeile lädt ein Wheel herunter und legt kirocrew in Ihrem kirocrew 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.8.0

Das Container-Image wird unter ghcr.io/kirodotdev/kirocrew veröffentlicht, für linux/amd64 und linux/arm64 unter jedem Tag. Für den Build aus dem Quellcode benötigen Sie git clone und make build. Dieser Pfad ist für Personen gedacht, die den Code ändern, nicht für Personen, die die Anwendung 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 diese Änderungen manuell zurücknehmen. Der Container hält die Laufzeitumgebung in einem Image und den Zustand in einem Volume. Für ein Rollback müssen Sie dadurch nur den Tag ändern und den Container neu starten.

Das Image auf einen Release-Tag festlegen, nicht auf stable

Das eigene Beispiel des Projekts 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 veränderlicher Tag. Das gilt auch für latest, der auf denselben Release verweist. Er verweist immer auf den neuesten stabilen Release. Dadurch kann der nächste Pull die verwendete Version ändern, ohne dass Sie dies auswählen. Außerdem ist am Tag nicht erkennbar, um welche Version es sich gehandelt hat. Versions-Tags sind unveränderlich. Verwenden Sie daher einen solchen Tag. Der neueste stabile Release zum 12 October 2026 ist 0.8.0. Er wurde am 9 October 2026 veröffentlicht. Es gibt außerdem die Tags insider und nightly. Bei einem so jungen Projekt bedeutet nightly, dass der Code heute Morgen geändert wurde.

Schreiben Sie /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.8.0
    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 fehlerfrei 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 abrufen

Der Container startet das Gateway, aber die Agent-Laufzeitumgebung 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. Rufen Sie anschließend ein Dashboard-Token ab:

docker exec kirocrew kirocrew token --ttl 2h

Die Dashboard-URL lautet http://localhost:5476/?token=<the token>. Tokens laufen ab: Der ausgegebene Link muss innerhalb von fünf Minuten nach dem Abruf geöffnet werden. Die dadurch geöffnete Sitzung ist standardmäßig eine Stunde gültig. Die dokumentierte maximale Gültigkeitsdauer beträgt zwanzig Stunden. Wenn ein Dashboard leer geladen wird oder Sie sofort wieder abgemeldet werden, ist das Token in der Regel abgelaufen. Rufen Sie dann ein neues Token ab und öffnen Sie es direkt. Fügen Sie ein Token niemals in ein Ticket oder eine Chatnachricht ein. Jeder, der das Token besitzt, kann Ihren Agent steuern.

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

Sehen Sie sich noch einmal die Bind-Adresse im Beispiel des Projekts 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 der Loopback-Schnittstelle des Hosts. Entfernen Sie das Präfix 127.0.0.1:, ist das Gateway im öffentlichen Internet für jeden erreichbar, der diesen Port scannt. Eine ufw-Regel schützt Sie ebenfalls nicht: Docker veröffentlicht Ports, indem es DNAT-Regeln schreibt, die den Datenverkehr weiterleiten, bevor die Regeln von ufw greifen. Deshalb bewirkt ufw deny 5476 bei einem veröffentlichten Port nichts. Die Lösung von Docker besteht darin, Filterregeln in der eigenen Kette DOCKER-USER zu hinterlegen. Das funktioniert, aber diese Regeln sehen die interne Adresse und den internen Port des Containers, sofern Sie nicht mit der conntrack-Erweiterung abgleichen. Die Bindung an die Loopback-Schnittstelle bleibt daher die einfachere und weniger fehleranfällige Kontrolle. Docker-Ports umgehen ufw erläutert diesen Mechanismus.

Leiten Sie den Port stattdessen von Ihrem Laptop über SSH weiter:

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

Lassen Sie diesen Prozess laufen und öffnen Sie lokal http://localhost:5476/?token=<the token>. Um die Weiterleitung bei jeder Verbindung automatisch einzurichten, 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. Rufen Sie anschließend http://localhost:45476/?token=... auf. Sobald ein zweiter Agent denselben Server verwendet, werden Sie Weiterleitungen wie diese stapeln: open-kritt für Sicherheitsscans selbst hosten richtet auf demselben Server ein weiteres Dashboard ein, das nur an die Loopback-Schnittstelle gebunden ist, auf Port 5173.

Zwei dokumentierte Verhaltensweisen bestimmen, welche Einstellungen Sie im Dashboard ändern können. Erstens behandelt das Gateway jede Anfrage mit Forwarding-Headern (Forwarded, X-Forwarded-* oder X-Real-IP) als remote. Seine Endpunkte zum Schreiben der Konfiguration und zum Anzeigen von Secrets weisen solche Anfragen zurück. Ein Reverse Proxy fügt diese Header hinzu. Eine einfache ssh -L-Weiterleitung fügt keine hinzu. Sie wirkt daher lokal und wird aus diesem Grund nicht abgewiesen. Zweitens sind die Seiten für Channel-Credentials und die Ansichten zum Anzeigen von Secrets im Container-Image für jeden Browser schreibgeschützt, der nicht direkt lokal zugreift. Das Image enthält außerdem keinen Texteditor. Wenn sich ein Channel-Credential nicht im Dashboard speichern lässt, ist das daher beabsichtigt und kein Fehler. Bearbeiten Sie die Konfiguration stattdessen 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 wird nicht unter einem öffentlichen Hostnamen bereitgestellt. Bevorzugen Sie diese Lösung gegenüber einem öffentlichen Reverse Proxy. Das Token wird in der URL übertragen. Eine URL wird auf ihrem gesamten Pfad in jedes Access-Log geschrieben. Diese Regel bezieht sich darauf, was hinter dem Port liegt, nicht auf den Port selbst: Etwas wie Halcyon, das eine Jellyfin-Bibliothek als durchsuchbaren Videoladen der 90er neu aufbaut, ist dafür gedacht, von anderen Personen geöffnet zu werden, und eignet sich daher für einen Reverse Proxy. Ein Gateway, das Befehle auf Ihrem Server ausführen kann, ist dafür nicht geeignet.

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 überhaupt etwas ausführen können. Wenn die Namespace-Isolation verfügbar ist, laufen die Agenten-Subprozesse isoliert. Wenn sie nicht verfügbar und KIROCREW_ALLOW_UNSANDBOXED=1 nicht gesetzt ist, wird die Ausführung verweigert, statt sie ohne Isolation auszuführen. Ein Gateway, das gesund aussieht, während jede Aufgabe hängen bleibt, ist daher meist auf dieses Problem zurückzuführen. Die Entscheidung wird beim ersten Lauf in docker logs kirocrew gespeichert. 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

Auf einem Host mit aktiviertem AppArmor ist das seccomp-Profil laut Docker-Anleitung des Projekts nur die halbe Änderung. Docker bindet zusätzlich sein docker-default-AppArmor-Profil ein und kombiniert es mit apparmor=unconfined. Diese Option hebt nur die AppArmor-Regeln pro Container auf. Das seccomp-Profil, die verworfenen Capabilities und der Nicht-root-Benutzer bleiben weiterhin aktiv.

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. Der Warnhinweis des Projekts sollte vollständig wiederholt werden. Binden Sie keine Host-Pfade ein, die Sie dem Agenten nicht direkt übergeben würden. In der Praxis schließt das den Docker-Socket, jeden Bind-Mount von / und jedes Verzeichnis aus, 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 kontoweitreichenden Berechtigungen. Führen Sie ihn als dedizierten Benutzer aus, dessen Home-Verzeichnis keine anderen Daten enthält. Genau dafür sind Benutzer mit minimalen 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 kurzlebige 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 bereinigen zu müssen. Dieselbe Überlegung gilt für den sicheren Betrieb von OpenClaw auf einem VPS und das Self-Hosting des Hermes-Agenten auf einem VPS. Auch Tools bestimmen 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 Abwehr von Prompt-Injection wie eine technische Konfigurationsentscheidung. Auch geplante Aufgaben verursachen Kosten, während Sie schlafen, da die Inferenz Ihrem Kiro-Tarif belastet wird. Legen Sie daher die in Kosten eines KI-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 setzen Sie ein fehlerhaftes Upgrade zurück?

Das Upgrade ist kurz, und es ist 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 System vorhanden ist. Daher besteht das gesamte Upgrade aus der Änderung des Tags. Das Zurücksetzen folgt derselben Abfolge mit der alten Versionsnummer. Dadurch erhalten Sie exakt das Image von zuvor, weil Versionstags unveränderlich sind.

Die Binärdateien lassen sich problemlos zurücksetzen. Der Zustand ist der problematische Teil. Ein neueres Gateway kann config.json neu schreiben oder die Memory-Datenbanken in eine Struktur migrieren, die ein älteres Gateway nicht lesen kann. Seit dem 12. Oktober 2026 ist kein Pfad für ein Downgrade des Zustands dokumentiert. Die Installationsanleitung ist in einem Fall eindeutig: Für Daten, die aus dem bisherigen ~/.kirocrew-Home verschoben wurden, gibt es keinen Rollback. Eine Version vor ~/.kiro/crew würde leer starten. Wenn das ältere Image startet und sich anschließend ungewöhnlich verhält, sollten Sie es nicht weiter 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. Aus demselben Grund funktioniert die Gewohnheit, jetzt zu upgraden und später ein Backup zu erstellen, bei einem noch so jungen Projekt nicht.

Was hier nicht bewiesen ist

Berücksichtigen Sie das Alter dieser Software. Version 0.1.3 war im August 2026, als dieser Leitfaden erstmals erstellt wurde, erst wenige Tage alt. Am 12. Oktober 2026 hatte die stabile Linie bereits 0.8.0 erreicht. Die meisten Release Notes sind weiterhin automatisch erzeugte Changelogs. Die 0.8.0-Hinweise sind zwar von Hand verfasst, enthalten aber keinen Abschnitt zur Migration. Außerdem umfasst die Upgrade-Historie erst etwa zwei Monate. Dieser Leitfaden enthält daher keine Langzeitergebnisse. Betrachten Sie Speicherwachstum, Datenbankgröße und die Zuverlässigkeit des Schedulers als Werte, die Sie auf Ihrem eigenen System messen müssen, nicht als Eigenschaften, von denen Sie ausgehen können.

Zwei Verhaltensweisen sollten Sie selbst testen, bevor Sie sich darauf verlassen. Prüfen Sie erstens, ob ein Downgrade den von einer neueren Version geschriebenen Zustand einliest. Testen Sie dies 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 Fälle können bei einem jungen Projekt zwischen Releases unauffällig behoben werden. Beide lassen sich jetzt mit geringem Aufwand überprüfen.

FAQ

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

Weil das veröffentlichte Beispiel den Port an die Loopback-Schnittstelle bindet. -p 127.0.0.1:5476:5476 ordnet den Port des Containers nur der Loopback-Adresse des Hosts zu. Das ist beabsichtigt. Leiten Sie den Port mit ssh -N -L 5476:127.0.0.1:5476 you@your-server über SSH weiter und ö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 über das öffentliche Internet erreichbar. ufw kann den Zugriff dann nicht begrenzen, weil die von Docker veröffentlichten DNAT-Regeln den Datenverkehr weiterleiten, bevor die ufw-Regeln greifen. Nur Regeln in der Docker-Kette DOCKER-USER filtern veröffentlichte Ports. Die Bindung an die Loopback-Schnittstelle ist daher einfacher.

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

Alle Daten liegen unter ~/.kiro/crew. Im Container-Image entspricht dieser Pfad /home/kirocrew/.kiro/crew, und KIROCREW_HOME verschiebt ihn. Sichern Sie das gesamte Verzeichnis oder das gesamte Docker-Volume, während das Gateway gestoppt ist. memory.db und memory_index.db sind SQLite-Datenbanken. Eine Kopie während eines Schreibvorgangs des Gateways kann daher inkonsistent sein. Beim Umzug auf einen neuen Host werden workspace/memory/, die beiden Datenbankdateien und config.json übernommen. PID-Dateien, das Sicherheitsereignisprotokoll und .env gehören dagegen zum alten Host.

Sollte ich das Tag stable oder ein Versionstag verwenden?

Verwenden Sie ein Versionstag. stable ändert sich bei jeder neuen Veröffentlichung. Dadurch kann sich die ausgeführte Version beim nächsten Pull ändern, ohne dass Sie dies erwarten. Außerdem sagt das Tag selbst nichts darüber aus, welche Version ausgeführt wird. Versionstags wie 0.8.0 sind unveränderlich. Genau deshalb funktioniert ein Rollback: Sie tragen die alte Versionsnummer wieder ein und erhalten dasselbe Image. Am 12. Oktober 2026 ist 0.8.0 die neueste stabile Version.

Warum verweigert mein Agent die Ausführung sämtlicher Befehle?

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

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

Ja, Stand Oktober 2026. KiroCrew ist freie Software unter Apache 2.0. Es steuert jedoch kiro-cli, wofür eine einmalige Anmeldung erforderlich ist. Die Inferenz des Agenten wird über einen Kiro-Plan 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. Im standardmäßigen Harness steht dem Agenten jedoch kein Modell zur Verfügung. Der Leitfaden des Projekts für benutzerdefinierte Backends ermöglicht es einem claude-Harness, die Modellinteraktionen mit dem Hauptmodell an einen von Ihnen ausgewählten Anthropic-kompatiblen Endpunkt zu senden. Die Anmeldung bei kiro-cli bleibt für Kiro-spezifische Funktionen dennoch erforderlich.