Les workers cloud d’OpenClaw

Les workers cloud déplacent le travail de code d’une session sur une machine cloud jetable pendant que la session reste visible dans la barre latérale et que sa transcription reste possédée par la passerelle. Le fournisseur Crabbox intégré démarre la machine, lance la configuration du profil, et l’enrôle comme nœud éphémère ; un seul profil configuré prend en charge à la fois les tours de worker OpenClaw et l’exécution distante Codex sur le même transport enrôlé. La fonction est facultative : tant qu’aucun profil n’existe, les clients cachent la destination Cloud. Voici ce qui tourne où, comment l’enrôlement et le nettoyage restent sûrs en cas de rejeu, les prérequis, le profil, et les règles de proxy.

Ce qui tourne où

• En mode tour de worker OpenClaw, l’environnement d’agent et la boucle de tour tournent sur la machine cloud dans un processus worker restreint, le travail de commandes, de fichiers et HTTP a lieu sur la machine, l’inférence du modèle et l’authentification du fournisseur restent sur la passerelle relayées par une référence de fournisseur et de modèle, et la transcription est alimentée par le flux d’événements rejouable du worker.
• En mode exécution distante Codex, le serveur d’application et la boucle de tour restent sur la passerelle avec son authentification de modèle, abonnement ChatGPT compris, tandis que les commandes tournent sur le nœud cloud, un appareil appairé, ou un fournisseur adossé à SSH.
• Dans les deux modes, les fichiers de l’espace de travail changent à distance et la passerelle les réconcilie ; le nœud cloud appelle le point d’accès TLS public de la passerelle par un WebSocket sortant, et le contrôle du worker et le transfert de l’espace de travail utilisent des canaux authentifiés plutôt qu’un tunnel inverse ou rsync.
• Une session cloud peut partir d’une URL de dépôt GitHub et d’une référence facultative sans copie locale sur la passerelle : le nœud récupère le dépôt, épingle le commit résolu et crée la branche de session, tandis que la passerelle garde les métadonnées de source et des points de contrôle immuables des changements acceptés ; les sessions issues d’une copie existante gardent leur miroir d’arbre de travail géré.

Quand le travail est terminé (ou que la machine meurt), la machine est jetée. La transcription, les changements d’espace de travail acceptés et les enregistrements de placement restent avec la passerelle.

Enrôlement et nettoyage

L’enrôlement appartient à l’environnement et résiste au rejeu : la passerelle conserve une identité de configuration avant l’enrôlement du nœud, lie la première identité d’appareil authentifiée à cet environnement exact, et réutilise le jeton d’appareil durable quand le provisionnement reprend. Récupérer ou détruire libère le bail cloud et retire l’appairage de nœud possédé par l’environnement, et si le provisionnement échoue avant de renvoyer un bail, le nettoyage résout la poignée de l’opération d’origine sans relancer provisionnement, configuration ni enrôlement, en ne se terminant qu’une fois que le fournisseur confirme la libération ou l’absence. Une valeur de configuration manquante ou un refus du fournisseur ne prouve pas qu’une tentative antérieure n’a rien alloué, donc ces échecs restent relançables sous l’identité d’opération d’origine. Les sessions en tour de worker peuvent aussi ouvrir des portails sur les workers adossés à un nœud par des tickets à usage unique échangés sur un WebSocket épinglé, en préservant l’expérience des portails de l’interface de contrôle sans ports entrants.

Prérequis et profil

• Une extension de fournisseur de workers, l’intégrée pilotant la CLI Crabbox, qui possède les backends cloud pris en charge ; une version de Node prise en charge et npm sur la machine louée, puisqu’OpenClaw n’installe pas Node ; la CLI GitHub sur le chemin du worker pour les commandes GitHub ; et une session de dépôt ou un arbre de travail géré vivant, jamais un simple répertoire arbitraire. Pour les workers AWS, le profil d’instance doit être vide, vérifié avant l’allocation.
• Les profils se gèrent sous les réglages de connexions de l’interface de contrôle ou sous la clé des workers cloud de la configuration, qui écrivent les mêmes clés : un identifiant de fournisseur, une préférence d’installation, une durée d’inactivité facultative avant suspension avec un minimum d’une minute où un worker suspendu ne facture que le stockage de l’instantané, et des réglages de fournisseur avec le backend, une classe de machine requise, une cible de système qui vaut Linux par défaut et peut être Windows par WSL2, Windows natif ou macOS, une durée de vie, un délai d’inactivité, un script de configuration idempotent facultatif, un bureau facultatif, et un chemin de binaire.
• Les images chaudes capturent un projet préparé et l’environnement de nœud avant l’enrôlement pour que les workers suivants de ce projet démarrent depuis l’image ; Linux seulement, activées par défaut quand une classe est connue, associées à la suspension pour que les sessions suspendues se réveillent chaudes, et facturées comme stockage d’instantané chez le fournisseur. Les identifiants Crabbox restent dans la configuration propre de Crabbox pour l’utilisateur de la passerelle, jamais dans les réglages du profil.

Le bac à sable d’OpenClaw expliqué est la réponse locale à la même question de rayon d’explosion, et Les nœuds d’OpenClaw, les mains distantes le modèle de périphériques que les workers cloud réutilisent.

Les règles de proxy

Pour une passerelle en boucle locale derrière une entrée HTTPS publique, le réglage d’origine publique doit être l’origine nue du proxy, la distribution cloud refuse les adresses de passerelle en boucle locale, de lien local ou non spécifiées avant d’allouer une machine, et tout proxy inverse devant, cloudflared, nginx ou un Tailscale Serve géré, doit figurer parmi les proxys de confiance, sinon l’enrôlement du nœud échoue avec une erreur d’attribution de proxy. Le proxy doit aussi transmettre la route des artefacts d’amorçage du worker avec l’en-tête d’autorisation intact, parce qu’un nouveau nœud télécharge son environnement par cette route authentifiée avant de pouvoir se connecter. Les sessions d’OpenClaw explique la session qui reste avec la passerelle d’un bout à l’autre, et La passerelle OpenClaw expliquée le processus qui la possède.

Sur Diali

Sur Diali, l’instance elle-même est la machine jetable en toute sécurité : elle fait tourner la boucle d’agent, garde l’espace de travail sur un volume persistant, et est remplacée à chaque release ; les workers cloud sont une fonction d’installation autogérée sans équivalent ici pour l’instant. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière.

• La machine est jetable ; la transcription ne l’est pas.
• Les tours de worker font tourner la boucle sur la machine ; Codex la garde sur la passerelle.
• Facultatif, un profil, les identifiants dans Crabbox.