Pourquoi l’architecture de runners distants OpenClaw compte
Le travail de type OpenClaw devient plus utile quand les agents continuent après la fermeture du portable. Mais un runner distant n’est pas une simple session SSH oubliée. C’est un espace jetable avec branche, identifiants limités, journaux, contrôles de santé et revue.
Office Claws n’est pas un runtime OpenClaw natif. Le cadrage honnête est de l’utiliser comme couche de contrôle desktop pour des opérations proches d’OpenClaw : provisionner et surveiller des runners VPS, garder les clés longues en local et utiliser Codex quand c’est le runtime pratique. Voir OpenClaw vs Codex et OpenClaw desktop manager.
La forme d’un runner distant OpenClaw
Une architecture sûre sépare cinq éléments : contrôle local, hôte runner, checkout isolé, frontière d’identifiants et revue.
| Couche | Rôle | Risque si absente |
|---|---|---|
| Contrôle local | tâches, clés, statut | secrets copiés sur tous les VPS |
| Hôte runner | CPU, réseau, durée | le sommeil du laptop coupe le travail |
| Checkout isolé | une tâche, une branche | agents en conflit |
| Frontière d’accès | token court et limité | injection avec accès trop large |
| Revue | PR, CI, humain | code en production trop tôt |
Le but est l’autonomie contrôlée, pas l’automatisation sans garde-fous.
Architecture de référence
Office Claws desktop
├─ clés fournisseur locales
├─ file de tâches et validations
└─ tableau de bord logs / santé
│
▼
pool de runners VPS
├─ runner-001: repo-a / branche-a / token limité
├─ runner-002: repo-a / branche-b / token limité
└─ runner-003: repo-b / branche-c / token limité
│
▼
GitHub PR + CI + revue humaineCe modèle rejoint OpenClaw background tasks, OpenClaw monitoring et OpenClaw remote SSH workflow.
Les frontières qui protègent les agents distants
Ne placez pas tous les jetons sur tous les runners. Gardez les clés longues en local, limitez chaque runner à un dépôt et une branche, utilisez des jetons GitHub courts, faites déployer CI, diffusez les logs et supprimez le runner après usage.
Office Claws for OpenClaw users met donc l’accent sur le contrôle desktop, les runners VPS, la visibilité des logs et la gestion locale des clés.
Dimensionnement et coût
| Charge | Runner suggéré | Note |
|---|---|---|
| docs, scripts, petits correctifs | 2 vCPU / 4 Go RAM | base économique |
| application web avec tests | 4 vCPU / 8 Go RAM | bon défaut |
| navigateur/E2E | 4-8 vCPU / 16 Go RAM | isoler les dépendances |
| grand monorepo | runner dédié | cache et limites |
Le coût se contrôle avec files, limites et destruction des runners, pas seulement avec des instances moins chères.
Checklist opérationnelle
- Tâche avec branche, dépôt et résultat attendu.
- Runner propre au démarrage.
- Identifiants limités et temporaires.
- Logs, état et diffs visibles.
- CI seul chemin de déploiement.
- Revue humaine avant merge.
À lire avec OpenClaw security best practices et OpenClaw secrets management.
Où Office Claws s’insère
Office Claws transforme cette architecture en workflow opérateur : contrôle local, runners VPS distants, suivi durable, logs et exécution Codex. Cela donne plus d’autonomie, moins d’état caché dans les terminaux et un rayon d’impact réduit.