Crew est conçu pour fonctionner en continu afin que son bot Slack, ses tâches cron et son exécuteur de tâches continuent de fonctionner pendant que vous êtes loin de votre bureau. Cette page couvre les quatre modèles de déploiement courants.
La façon la plus simple est l'installateur intégré. Il enregistre un service au niveau du système — systemd sur Linux, launchd sur macOS — pour que la passerelle survive aux déconnexions SSH, redémarre automatiquement en cas de plantage et démarre automatiquement au démarrage du système.
kirocrew service install # registers the unit + starts it kirocrew service status # check running state kirocrew logs -f # tail live logs kirocrew restart # atomic restart (systemd) or unload+load (launchd) kirocrew service uninstall # remove
Sur Linux, l'étape d'installation demande le mot de passe sudo une fois pour écrire le fichier unit. La passerelle elle-même s'exécute sous votre utilisateur (User=$USER Group=$(id -gn)), pas sous root. La survie au démarrage est gérée par le WantedBy=multi-user.target de l'unité, ainsi que enable --now — rien de plus à configurer.
Portée de sudo. kirocrew service install exécute seulement sudo tee (pour écrire le fichier unit sous /etc/systemd/system/) et sudo systemctl ... (daemon-reload, enable, restart). Aucun chemin de code kirocrew, MCP ou LLM ne s'exécute sous sudo.
Si vous préférez éviter complètement le service, tmux survit à la déconnexion SSH mais ne redémarre pas automatiquement en cas de plantage ni au redémarrage du système :
tmux new -s kirocrew kirocrew gateway # Ctrl+B, D to detach # Reconnect with: tmux attach -t kirocrew
Pour les serveurs toujours actifs — bots Slack/Discord, tableaux de bord distants — la passerelle est livrée sous forme d'image multi-architecture sur GHCR. C'est le choix le plus adapté pour un bot de canal sans interface qui n'a pas besoin d'une session de bureau.
docker run -d --name kirocrew \ -p 127.0.0.1:5476:5476 \ -v kirocrew-home:/home/kirocrew \ ghcr.io/kirodotdev/kirocrew:stable
Ou avec Docker Compose — copiez docker/compose.yaml du dépôt et exécutez docker compose up -d.
Deux étapes ponctuelles après le démarrage du conteneur :
# 1. Log in the agent runtime (survives upgrades — credentials live in the volume) docker exec -it kirocrew kiro-cli login # 2. Mint a dashboard login link (every request requires a token) docker exec kirocrew kirocrew token --ttl 2h
Les liens de connexion expirent quelques minutes après leur création — créez-les, puis ouvrez-les immédiatement. La passerelle affiche aussi un lien au démarrage, mais au moment où vous lisez docker logs, il a généralement déjà expiré, donc la création via docker exec est la méthode fiable.
| Étiquette | Signification |
|---|---|
stable / latest | Dernière version stable publiée (change à chaque publication stable) |
insider | Dernière préversion insider |
nightly | Dernière build nightly |
0.1.0, 0.1.0-nightly.202607261234 | Versions exactes immuables |
linux/amd64 et linux/arm64 sont publiées sous chaque étiquette. Les étiquettes de version ne sont jamais réattribuées une fois publiées — épinglez une étiquette de version ou un digest pour des déploiements reproductibles. Chaque manifeste porte une provenance de build SLSA :
gh attestation verify oci://ghcr.io/kirodotdev/kirocrew:stable --repo kirodotdev/KiroCrew
Les identifiants des canaux se chargent depuis l'environnement (ou depuis .env dans le répertoire de données). Passez-les avec -e ou un bloc environment: de compose :
| Variable | Objectif |
|---|---|
SLACK_BOT_TOKEN, SLACK_APP_TOKEN, KIROCREW_OWNER_ID | Bot Slack (mode Socket) |
DISCORD_BOT_TOKEN | Bot Discord |
KIROCREW_PORT | Port du tableau de bord (par défaut 5476) |
KIROCREW_BIND | Adresse de liaison à l'intérieur du conteneur (valeur par défaut de l'image 0.0.0.0) |
KIROCREW_ALLOW_UNSANDBOXED | Définissez 1 pour autoriser explicitement l'exécution de l'agent sans le bac à sable interne |
À chaque démarrage, le point d'entrée déplace tous les identifiants de canaux qu'il trouve dans l'environnement vers le fichier .env du répertoire de données (mode 600) et les retire de l'environnement de la passerelle avant que celle-ci ne démarre — pour qu'ils ne se retrouvent jamais dans le /proc/<pid>/environ du processus de longue durée. Les valeurs de l'environnement l'emportent sur celles stockées précédemment.
0.0.0.0 à l'intérieur du conteneur. À l'extérieur de Docker, la passerelle se lie uniquement à loopback. À l'intérieur d'un conteneur, les ports publiés sont mappés à l'interface pont du conteneur, donc une liaison loopback serait inaccessible depuis l'hôte. L'image se lie à toutes les interfaces à l'intérieur de l'espace de noms réseau du conteneur — rien n'est accessible jusqu'à ce que vous publiiez le port, et -p 127.0.0.1:5476:5476 le garde local à l'hôte./api/health, /api/live, /api/ready), les ressources statiques (amorçage SPA) et les points de terminaison d'amorçage locaux qui exigent un pair loopback ainsi qu'un secret sur le système de fichiers.agent.sandbox="auto". Sinon, l'exécution des commandes de l'agent reste désactivée (fermeture par défaut) — la passerelle, le tableau de bord et les bots de canaux fonctionnent normalement. Pour activer les agents sans le bac à sable, redémarrez avec -e KIROCREW_ALLOW_UNSANDBOXED=1.Tout l'état persistant — répertoire de la passerelle, identifiants kiro-cli, agents, skills — se trouve sous /home/kirocrew dans un seul volume nommé. Effectuez une mise à niveau en récupérant une image plus récente; l'état est conservé :
docker compose pull && docker compose up -d
Il n'y a pas de mise à jour automatique dans le conteneur. L'image est immuable; l'étiquette est le sélecteur de version.
Exécutez Crew sur un hôte Linux distant toujours actif — un VPS, une VM cloud ou une machine de rechange — pour que Slack, cron et l'exécuteur de tâches continuent de fonctionner pendant que votre ordinateur portable est en veille.
slack-mcp.Le tableau de bord se lie à localhost:5476 sur l'hôte distant. N'exposez pas ce port publiquement — redirigez-le vers votre machine locale par SSH :
ssh -L 5476:localhost:5476 user@your-host.example.com
Puis ouvrez http://localhost:5476 dans votre navigateur local.
Rendez le tunnel automatique à chaque connexion SSH avec ~/.ssh/config sur votre machine locale :
Host your-host.example.com LocalForward 5476 localhost:5476
Maintenant, ssh your-host.example.com configure toujours le tunnel. Cela fonctionne sur macOS, Linux et Windows (OpenSSH est intégré à Windows 10+).
Un tunnel SSH ad hoc meurt quand le terminal se ferme. Pour le garder en fonctionnement de façon permanente — il survit aux redémarrages et se reconnecte lors des interruptions réseau — utilisez un LaunchAgent qui supervise un processus ssh -N. Consultez le guide de bureau distant dans le dépôt Crew pour le plist exact.
Lors de la configuration d'un nouvel hôte distant, synchronisez votre état local pour que l'instance distante ait vos mémoires, préférences, leçons et configurations d'agent dès le premier jour.
| Catégorie | Chemin | Pourquoi |
|---|---|---|
| Mémoire | ~/.kiro/crew/workspace/memory/ | Préférences, projets, historique |
| Bases de données | ~/.kiro/crew/memory.db, .db-wal, .db-shm, memory_index.db | Épisodique + sémantique (SQLite + WAL pour un état complet) |
| Configuration | ~/.kiro/crew/config.json | Paramètres et préférences de modèle |
| Specs de tâches | ~/.kiro/crew/tasks/ | Specs d'exécuteur de tâches enregistrées |
| Skills | ~/.kiro/crew/skills/ | Définitions de skills personnalisées |
| Tâches cron | ~/.kiro/crew/crons.json | Tâches récurrentes planifiées |
Ne synchronisez pas ~/.kiro/crew/.env, .local_secret ou sel_hmac.key — ce sont des secrets propres à l'hôte, régénérés à la première exécution.
Le dépôt fournit un script autonome scripts/sync-to-remote.sh qui gère la sauvegarde atomique de SQLite, la prise en charge de ports personnalisés, la synchronisation de session pour l'historique de clavardage et l'application de correctifs de configuration à distance. Exécutez-le depuis votre machine locale :
scripts/sync-to-remote.sh user@your-host.example.com scripts/sync-to-remote.sh --dry-run # preview without transferring
Accédez au tableau de bord depuis votre téléphone en exposant le port local par un tunnel HTTPS nommé et en pointant les liens présignés du bot Slack vers l'URL du tunnel.
Le tableau de bord se lie à localhost:5476 sur l'hôte qui exécute Crew, quel qu'il soit. Un service de tunnel — Cloudflare Tunnel, ngrok ou Tailscale Funnel — vous donne une URL HTTPS publique stable qui fait office de proxy vers ce port local. Définissez l'URL du tunnel comme dashboard.url et le bot Slack génère des liens que votre téléphone peut ouvrir.
Créez un tunnel nommé qui produit une URL stable qui ne change pas entre les redémarrages. Avec cloudflared, par exemple :
# One-time: authenticate and create the named tunnel cloudflared tunnel login cloudflared tunnel create kirocrew # Route a hostname you control to the tunnel, then run it pointed at port 5476 cloudflared tunnel route dns kirocrew kirocrew.example.com cloudflared tunnel --url http://localhost:5476 run kirocrew
Quel que soit l'outil que vous utilisez, l'objectif est le même : une URL HTTPS stable qui fait office de proxy vers le port 5476.
Définissez dashboard.url dans ~/.kiro/crew/config.json :
{ "dashboard": { "url": "https://kirocrew.example.com" } }
Redémarrez la passerelle. Ensuite, dans Slack, tapez /kirocrew dashboard (ou /kirocrew dashboard 6h pour une session plus longue). Le bot vous envoie un lien présigné en message direct — touchez-le sur votre téléphone pour ouvrir le tableau de bord dans votre navigateur mobile.
| Couche | Durée | Notes |
|---|---|---|
| Jeton de tableau de bord | 1 heure par défaut, jusqu'à 20 heures | Configurable via /kirocrew dashboard 6h; limite pratique de session |
| Fenêtre de clic du lien présigné | 5 minutes | Doit être cliqué avant son expiration |
La plupart des fournisseurs de tunnel offrent aussi un installateur de service (cloudflared service install) pour que le tunnel démarre automatiquement au démarrage du système — recommandé pour les configurations 24/7.
kirocrew doctor signale l'état de kiro-cli, son authentification, les embeddings, les jetons Slack, la validité de la configuration et les serveurs MCP. Exécutez-le chaque fois que la passerelle semble en mauvais état ou après un changement de configuration.
kirocrew doctor
Fonctionnement 24/7