OpenClaw cloud vs local n’est pas une question de doctrine. Nous choisissons l’endroit qui rend la prochaine tâche la plus contrôlable : local quand les clés, la revue et l’intention priment ; cloud ou VPS quand l’isolation, la disponibilité et le parallélisme comptent davantage.
Office Claws n’est pas un runtime OpenClaw natif. C’est la couche d’exploitation pour les équipes aux workflows proches d’OpenClaw qui veulent un contrôle desktop local, des files visibles, une gestion plus sûre des clés et des runners adossés à Codex lorsque c’est le chemin d’exécution pragmatique. Si le choix du runtime reste ouvert, commencez par OpenClaw vs Codex, puis utilisez ce guide pour placer le travail.
OpenClaw cloud vs local : le vrai compromis
Les agents locaux sont plus faciles à surveiller. Ils héritent du contexte de l’opérateur, gardent les secrets près de lui et rendent visible le moment où une revue humaine reste nécessaire. Les agents cloud restent plus facilement actifs. Ils survivent à la veille d’un laptop, utilisent des machines propres et traitent des branches parallèles sans partager le même checkout.
L’erreur consiste à croire qu’un côté est toujours plus sûr. Un runner local avec une .env partagée et aucune règle de branche peut être pire qu’un VPS verrouillé. Un runner cloud avec des tokens larges et des logs cachés peut faire croire qu’une petite tâche est terminée avant la revue du diff.
| Question | Plutôt local | Plutôt cloud / VPS |
|---|---|---|
| Où doivent vivre les clés fournisseur ? | Près de l’opérateur desktop | Seulement si elles sont limitées et renouvelées |
| Combien de temps dure la tâche ? | Minutes, forte revue | Heures, builds lourds, async |
| La surface de dépendances est-elle risquée ? | Repo connu, petite modification | Installation inconnue ou code généré |
| Combien d’agents tournent ensemble ? | Un ou deux | Plusieurs branches isolées |
| Que faut-il préserver ? | Intention, contexte de revue | Logs, artefacts, disponibilité |
C’est pourquoi Office Claws for OpenClaw users garde le plan de contrôle local même quand l’exécution part vers un runner VPS connecté via Tailscale ou DigitalOcean.
Une règle de décision que nous utilisons vraiment
Avant d’envoyer du travail à un agent, nous écrivons le contrat d’exploitation. Il est assez petit pour rester utile et assez strict pour repérer les défauts dangereux.
openclaw_task:
goal: refactor-billing-copy
control_plane: local-desktop
runner: choose-local-unless-long-running
branch: one-task-one-branch
secrets: no-shared-env-files
gates:
- npx velite build
- npm run build
- human-review-before-mergeUtilisez l’exécution locale quand la tâche dépend surtout du jugement : textes, petits correctifs UI, tests ciblés ou tout travail nécessitant un pilotage humain rapide. Utilisez un runner VPS pour une machine propre, une longue durée, des essais de dépendances ou du travail parallèle.
Pour la partie distante, associez ce guide à OpenClaw on VPS, OpenClaw remote runner architecture et OpenClaw sandbox.
Comment Office Claws sépare contrôle et exécution
Nous aimons le modèle séparé : desktop local pour commander, runners distants pour l’exécution jetable. Le desktop possède la file, les approbations, l’état et la revue finale. Le runner possède le checkout, la branche, les logs et les artefacts de build d’une seule tâche.
Cela évite les deux extrêmes habituels. Nous ne voulons pas que chaque agent soit bloqué sur un laptop qui peut dormir pendant une migration. Nous ne voulons pas non plus pousser chaque credential et chaque décision dans une machine cloud seulement parce que c’est pratique.
Une configuration pratique ressemble à ceci :
- Démarrer chaque tâche depuis la file desktop Office Claws.
- Garder les identifiants fournisseur et release locaux sauf besoin réel d’accès limité côté runner.
- Assigner un runner, un checkout et une branche par tâche.
- Diffuser logs et état vers le desktop au lieu de cacher le travail dans SSH.
- Exiger la sortie de build et une décision humaine de merge avant le déploiement.
Les équipes self-hosted peuvent utiliser leur compte DigitalOcean pour $4.99/mois plus les coûts d’infrastructure. Les équipes managed peuvent laisser Office Claws gérer la couche VPS à partir de $14.99/mois. Le contrat de workflow reste identique.
Recommandations
Commencez local pour établir la confiance. Passez au cloud ou au VPS pour l’isolation, la disponibilité et le parallélisme. Gardez la revue humaine visible dans les deux cas.
Si vous construisez aujourd’hui un modèle proche d’OpenClaw, suivez cet ordre :
- Lisez OpenClaw vs Codex si le choix du runtime reste ouvert.
- Utilisez OpenClaw security best practices pour définir secrets, approbations et logs.
- Utilisez OpenClaw VPS manager quand les runners distants deviennent le choix le plus sûr.
- Gardez Office Claws comme centre de commande local afin que la montée en charge cloud n’efface pas le contrôle humain.
Cloud vs local est le mauvais binaire. La meilleure question est : où cette tâche peut-elle tourner avec le plus petit rayon d’impact et le chemin de revue le plus clair ? C’est le modèle d’exploitation autour duquel Office Claws est construit.