Multi-instance

Exécutez Crew sur des hôtes de développement distants, des instances EC2, des serveurs personnels ou des tâches Fargate jetables et accédez-y depuis un seul tableau de bord local. Les instances longue durée exposent une passerelle loopback via un transfert de port SSH ou AWS SSM. Fargate expose une API de tour limitée à la tâche via AWS SSM, sans règle réseau entrante.

Activation volontaire. Désactivé par défaut.

Définissez instances.enabled à true, puis activez Settings → Developer → Feature Previews → Chat on a crew. Ouvrez le menu de nouvelle conversation, choisissez New chat on crew et sélectionnez une instance Crew connectée.

La transcription reste locale tandis que chaque tour s'exécute sur l'instance Crew distante sélectionnée. La barre latérale affiche le nom Crew et l'insigne du serveur. Le comportement de connexion automatique se configure dans Settings → Remote crews → Auto-connect crews.

kirocrew config set instances.enabled true

Ce paramètre s'applique en direct dans la version 0.7. Le Gateway crée le registre des instances et commence à gérer les connexions admissibles sans redémarrage manuel.

Utilisez un nom d'hôte, user@host ou un alias de configuration SSH. L'authentification doit fonctionner sans invite interactive, normalement via ssh-agent ou un fichier d'identité configuré.

Utilisez un ID d'instance EC2 ou un ID d'instance gérée SSM avec un profil AWS et une région. La machine locale nécessite l'AWS CLI et le plugin Session Manager, et l'instance distante nécessite l'agent SSM ainsi que les permissions IAM requises. La connexion utilise le transfert de port et ne nécessite pas de règle SSH entrante.

Fargate est conçu pour les travailleurs distants jetables. Crew s'exécute en tant que tâche ECS et est accessible via un transfert SSM vers son API de tour, sans écouteur public ni tableau de bord distant intégré. Configurez le placement Fargate, l'image épinglée par condensé et les références aux secrets dans le bloc facultatif fargate de cloud.json; la surface Cloud affiche l'état de la connexion et de la tâche.

Une tâche dure six heures par défaut. Définissez fargate.task_ttl_seconds pour choisir une durée de vie positive différente. Le moteur d'exécution admet au plus dix tâches Crew Fargate à la fois; ce plafond de sécurité est fixe plutôt qu'un paramètre de cloud.json.

L'ordinateur portable qui se connecte nécessite l'AWS CLI et le plugin Session Manager. Fargate utilise les mêmes contrôles de gestion de crew à distance réservés au propriétaire que les autres méthodes de connexion.

 ┌── Hub gateway (this host) ──┐
 │  /instances page (React)     │
 │  ├─ tab strip: Home · A · B  │
 │  ├─ warm <iframe>s per tab   │  http://127.0.0.1:<local_port>/?token=…
 │  └─ Manage panel             │  add / connect / diagnose / restart / remove
 │                              │
 │  instances/ package          │
 │  ├─ registry                 │  ~/.kiro/crew/instances.json
 │  ├─ port_allocator           │  loopback ports from base 7778
 │  ├─ token_mint               │  ssh <host> kirocrew token → JWT (never logged)
 │  ├─ ssh_tunnel_manager       │  supervised ssh -N -L, probe, self-heal, refresh
 │  └─ diagnostics              │  ssh → remote-dashboard → local-forward ladder
 └──────────────────────────────┘
         │ ssh -N -L 127.0.0.1:<local>:127.0.0.1:<remote>
         ▼
 ┌── Remote gateway ────────────┐
 │  kirocrew gateway bound to    │
 │  127.0.0.1:<remote_port>      │
 └──────────────────────────────┘

Chaque instance que vous ajoutez produit un processus enfant supervisé ssh -N -L. Le tunnel transfère 127.0.0.1:<local> → distant 127.0.0.1:<remote>. Le hub émet un jeton de tableau de bord sur l'instance distante via SSH et intègre le tableau de bord distant dans un iframe à l'URL loopback.

1. Connexion — POST /api/instances/{id}/connect alloue un port loopback, émet un jeton sur l'instance distante via SSH, démarre ssh -N -L, attend que le transfert local accepte une connexion, puis renvoie l'état en direct
2. Ensemble actif — par défaut, l'ensemble actif s'ajuste automatiquement pour les instances admissibles, avec un plafond de 8; définissez instances.warm_set_cap sur une valeur positive pour fixer une limite. Les instances actives conservent un tunnel + WebSocket en direct. Se connecter au-delà du plafond évince paresseusement la moins récemment utilisée
3. Sonde de santé — pendant la connexion, une sonde interroge le transfert loopback toutes les 30 s; après 3 échecs consécutifs, elle arrête le processus enfant pour déclencher la récupération
4. Autoréparation à 2 niveaux — en cas d'arrêt inattendu : le niveau 1 reconstruit le tunnel en réutilisant le jeton existant; le niveau 2 réémet le jeton puis reconstruit. Limité à 8 tentatives avec un délai exponentiel plafonné (fenêtre d'environ 2 min)
5. Renouvellement proactif du jeton — une boucle par instance réémet le jeton à 0,8 de sa durée de vie (TTL), avant le plafond d'environ 20 h
6. Diagnostic / redémarrage — ?diagnose=1 exécute une série de sondes de défaillance à la demande; POST .../restart redémarre la passerelle distante via SSH

Ouvrez Settings → Remote crews, sélectionnez Add et choisissez la méthode de connexion.

Toutes les méthodes prennent un nom d'affichage. Les passerelles SSH et SSM longue durée utilisent également une durée de vie du jeton de tableau de bord. Une valeur commençant par - ou une cible qui ne correspond pas à sa méthode est refusée avant le démarrage d'un processus enfant.

Utilisez votre alias de configuration SSH ou user@hostname. L'authentification doit réussir de façon non interactive via ssh-agent ou des clés configurées.

Configurez un alias SSH sur le hub, puis utilisez cet alias comme cible SSH :

Host my-ec2
  HostName ec2-1-2-3-4.compute-1.amazonaws.com
  User ec2-user
  IdentityFile ~/.ssh/my-key.pem
  ProxyJump bastion-host

Pour une instance EC2 sans port SSH entrant, choisissez AWS SSM directement ou utilisez une ProxyCommand SSM dans l'alias SSH.

Prérequis sur le hub :

• Une clé sans phrase de passe ou un ssh-agent la détenant (BatchMode ne demandera pas d'invite)
• kirocrew installé et une passerelle en cours d'exécution sur le port loopback de l'instance EC2

Le panneau Manage vous offre les actions suivantes par instance :

• Connect — ouvrir un tunnel + iframe
• Disconnect — fermer le tunnel
• Diagnose — exécuter la série de sondes de défaillance et signaler le premier lien rompu
• Restart — redémarrer la passerelle distante via SSH (avec prise en compte du service)
• Edit — modifier le nom / l'hôte / le port / le TTL
• Remove — déconnecter puis supprimer

Chaque route de /api/instances/* est protégée par _guard() :

• Refus par défaut — rejette les requêtes provenant de Slack (403)
• Réservé au propriétaire — exige request["user"] (session de tableau de bord authentifiée)
• Contrôlé par fonctionnalité — exige instances.enabled: true
• Audité par SEL — chaque appel (réussite et refus) émet un événement d'audit

Au-delà de la protection :

• Transferts loopback uniquement — ssh -N -L 127.0.0.1:<local>:127.0.0.1:<remote>
• Aucun shell local — ssh est toujours invoqué avec une liste argv; ssh_host ne peut pas injecter de syntaxe shell locale
• Entrées validées par jeu de caractères — ssh_host et remote_bin sont rejetés s'ils contiennent des métacaractères shell ou commencent par -
• Jetons de courte durée — ≤20 h, renvoyés uniquement en mémoire à l'appelant, jamais journalisés, jamais dans les charges utiles de liste/état
• Vérification de l'origine postMessage — le parent valide chaque event.origin de trame intégrée par rapport à l'exact http://127.0.0.1:<port> d'un tunnel actuellement actif avant de faire confiance à un message de compte de non-lus

Pour instances.enabled et les autres paramètres des instances multiples, consultez Configuration.