Auto-héberger un workflow façon OpenClaw semble simple : louer un VPS, installer un agent, le pointer vers un dépôt. Ce qui piège les équipes, c’est tout ce qui entoure cette boucle : secrets, branches, logs, plafonds de dépense et chemin de reprise quand une longue tâche se bloque au milieu d’une migration.
Voici le modèle d’exploitation que nous recommandons aux utilisateurs OpenClaw qui veulent plus de contrôle sans prétendre qu’Office Claws est un runtime OpenClaw natif. Office Claws gère l’état local du desktop et des runners VPS pour des agents adossés à Codex. Si votre charge OpenClaw est surtout du travail de dépôt, cela donne la forme self-hosted utile : vos clés restent locales, chaque tâche obtient un runner isolé et chaque changement arrive encore comme une branche révisable.
Ce que « OpenClaw Self Hosted » devrait signifier
La définition la plus sûre n’est pas « copier le service hébergé sur un serveur ». C’est une séparation du plan de contrôle.
| Couche | Où la garder | Pourquoi c’est important |
|---|---|---|
| Contrôle desktop | Machine locale | Tokens API, clés SSH, approbations et intention de l’opérateur restent près du développeur |
| Exécution agent | Runner VPS | Les longues tâches survivent à la veille du laptop et au Wi-Fi instable |
| Changements repo | Branche par tâche | Review, CI et rollback restent normaux |
| Accès réseau | Mesh privé | SSH n’est pas exposé directement à internet |
| Facturation | Abonnement + petit VPS | Les coûts sont prévisibles au lieu de transformer chaque retry idle en surprise API |
Ce modèle est différent d’un OpenClaw exécuté tel quel. Nous ne disons pas qu’Office Claws importe les extensions, la mémoire ou les automatisations navigateur d’OpenClaw. Nous décrivons un workflow self-hosted pour les utilisateurs OpenClaw qui ont surtout besoin de coding autonome sur des machines durables. La comparaison OpenClaw vs Codex est le meilleur endroit pour décider si cet échange vous convient.
L’architecture de référence
Un setup self-hosted fiable comporte quatre éléments :
- Office Claws sur le desktop pour le provisionnement, les approbations, le statut et la gestion locale des clés.
- Un VPS par runner actif chez Contabo, DigitalOcean, Hetzner ou un fournisseur que vous connaissez déjà.
- Tailscale ou un mesh privé équivalent pour que les runners n’exposent pas SSH à internet.
- Codex CLI dans le runner pour le chemin d’exécution orienté dépôt dont beaucoup d’utilisateurs OpenClaw ont besoin après un changement d’abonnement ou de coût.
L’habitude essentielle : une tâche, un runner, une branche. Ne laissez pas trois agents partager un checkout parce que cela semble efficace. C’est ainsi qu’une expérience self-hosted bon marché devient des diffs mystérieux et des sorties de tests écrasées. Le guide OpenClaw desktop manager explique pourquoi l’UI rend l’état du runner si visible : si vous ne savez pas quel agent possède quel dépôt, vous n’avez pas encore de couche d’exploitation.
Checklist de setup
Commencez petit. Un runner suffit à prouver la boucle.
# target shape, not a magic installer
1. create a VPS from a known snapshot
2. join it to your private mesh
3. authenticate Codex CLI on the runner
4. clone one repo into one task workspace
5. create a branch before the agent edits files
6. run tests and push the branch
7. destroy or reset the runner when the task is donePour les utilisateurs Office Claws, l’app gère le provisionnement et le statut ; vous gardez la responsabilité des permissions du dépôt, des règles de review GitHub et du compte modèle. Le plan self-hosted coûte $4.99/mois pour la gestion desktop/VPS, tandis qu’un runner managed coûte $14.99/mois si vous voulez moins posséder le serveur. Gardez ces chiffres séparés de votre abonnement modèle et de la facture VPS.
Avant de confier du vrai travail au runner, vérifiez les contrôles ennuyeux :
- Token GitHub limité : accès au dépôt seulement, pas de token admin à l’échelle de l’organisation.
- Pas de prolifération
.envpartagée : ne transmettez que les secrets nécessaires à la tâche. - Plafond de dépense : définissez-en un chez le fournisseur VPS et, si possible, dans le workflow du compte modèle.
- Gate CI : aucun déploiement direct depuis une branche d’agent.
- Chemin de reset : snapshot ou rebuild doit être plus rapide que déboguer un runner empoisonné.
Ce sont les mêmes contrôles que dans OpenClaw security best practices. Le self-hosting retire une surface fournisseur, mais ajoute de la responsabilité ; il ne rend pas le travail d’agent sûr par magie.
Modes de panne à anticiper
La plupart des problèmes d’agents self-hosted sont prévisibles. Concevez le système pour eux avant la première exécution de nuit.
| Mode de panne | Symptôme | Garde-fou |
|---|---|---|
| Collisions de workspace partagé | Deux agents modifient les mêmes fichiers | Un runner et une branche par tâche |
| SSH public exposé | Tentatives de connexion aléatoires dans les logs | Mesh privé uniquement ; SSH public fermé |
| Secrets trop larges | L’agent peut lire des identifiants sans rapport | Env par tâche et tokens limités |
| Blocage silencieux | Le job s’arrête après un prompt ou un test échoué | Checks de statut, logs et reprise explicite |
| Dérive de coût | Des runners restent actifs tout le week-end | Plafonds de dépense et nettoyage des runners |
La couche de statut compte plus qu’on ne le pense. Un multiplexeur de terminal peut garder une session vivante, mais il ne répond pas aux questions de l’opérateur : qui possède cette tâche, quelle branche a été poussée, les tests sont-ils passés, et peut-on supprimer la machine ? C’est pourquoi nos articles OpenClaw reviennent vers Office Claws pour les utilisateurs OpenClaw au lieu de prétendre qu’un VPS nu suffit.
Recommandation
Si votre travail OpenClaw est surtout du code, auto-hébergez d’abord la couche d’exploitation, pas tout le reste. Gardez approbations et identifiants en local. Exécutez les agents sur des runners VPS privés. Utilisez l’exécution adossée à Codex quand elle convient. Faites passer chaque résultat par GitHub et CI comme la branche d’un coéquipier.
Si votre travail OpenClaw dépend d’extensions natives, d’automatisations navigateur lourdes ou de flux spécifiques à une plateforme, ne le forcez pas dans ce modèle. Gardez OpenClaw pour ces tâches et utilisez Office Claws pour le travail de dépôt qui profite de runners durables moins chers.
Le meilleur setup self-hosted est volontairement ennuyeux : une tâche, un runner, une branche, une porte de review. C’est le but. Le coding autonome devient beaucoup plus fiable quand l’infrastructure refuse d’être trop maligne.