Héberger OpenClaw : VPS, Docker ou cloud
Où héberger OpenClaw ? Comparez VPS et cloud, puis sécurisez le Gateway, ses données, ses mises à jour et ses sauvegardes.
Introduction
Héberger OpenClaw revient à faire tourner son Gateway en continu sur une machine que vous contrôlez. Ce service Node/TypeScript relie vos canaux de messagerie à votre assistant, conserve les sessions et exécute outils, skills et automatisations. Un VPS convient à un utilisateur avancé prêt à administrer Linux ; une offre plus managée réduit l’exploitation au prix d’un contrôle moindre. Docker reste optionnel : c’est un mode d’isolation, pas un hébergeur. Ce guide compare les choix, les coûts et la sécurité sans présenter OpenClaw comme un SDK Python. Pour une machine éphémère ou un simple essai local, un serveur permanent serait inutile.
Résumé rapide
| Choix | Atout principal | Limite | Verdict |
|---|---|---|---|
| VPS Linux | Contrôle, prix prévisible | Administration à votre charge | Meilleur défaut pour un assistant personnel permanent |
| Docker sur VPS | Isolation et déploiement reproductible | Volumes, réseau et permissions à gérer | Utile, mais non obligatoire |
| Cloud managé | Déploiement simplifié | Coût et contraintes de plateforme | À choisir si l’exploitation prime sur le contrôle |
| Machine locale | Accès direct aux fichiers et appareils | Dépend de sa disponibilité | Idéale pour tester, moins pour du 24/7 |
Comprendre ce qui doit être hébergé
OpenClaw est un assistant IA personnel self-hosted. Son cœur opérationnel est un Gateway toujours actif : un processus unique gère le plan de contrôle, les connexions aux canaux, le routage des messages, les sessions, le tableau de bord et les automatisations. Par défaut, son port est 18789 et son bind est limité à la boucle locale. La configuration principale se trouve dans ~/.openclaw/openclaw.json ; l’état, les historiques et le workspace vivent sous ~/.openclaw sauf surcharge explicite.
Cette architecture change le dimensionnement. Le serveur ne doit pas héberger un hypothétique runtime Python par agent. Il doit surtout absorber le processus Node, les connexions persistantes, les fichiers de travail, les outils lancés par l’agent et, éventuellement, le navigateur ou des sandboxes. La consommation varie donc davantage selon les outils et le nombre de sessions que selon le nombre de canaux configurés.
Le VPS devient la source de vérité : sauvegardez séparément le répertoire d’état et le workspace. Une restauration qui ne récupère que openclaw.json ne rend ni les sessions ni les fichiers de travail. À l’inverse, copier tout ~/.openclaw sans protéger les credentials crée un risque de fuite.
Docker n’est pas requis. La documentation officielle le recommande surtout pour un environnement isolé, jetable ou un hôte sans installation locale. Une installation normale avec openclaw onboard --install-daemon crée un service supervisé ; sur Linux, il s’agit d’un service systemd utilisateur. Pour comparer les étapes d’installation, consultez OpenClaw sur VPS.
Choisir et préparer le serveur OpenClaw
Dimensionner sans surpayer
La documentation Docker demande au moins 2 Go de RAM pour construire l’image, car l’installation des dépendances peut échouer sur une VM de 1 Go. Pour un petit Gateway sans navigateur permanent, partez raisonnablement sur 2 vCPU, 4 Go de RAM et 40 Go de SSD. Ce n’est pas un minimum contractuel : c’est une marge pratique pour les mises à jour, les logs et quelques outils.
Montez à 8 Go si vous utilisez Chromium, plusieurs sandboxes, de gros traitements de fichiers ou des commandes parallèles. Mesurez avant d’augmenter : CPU, mémoire résidente, espace disque et durée des tours d’agent sont plus utiles qu’un nombre abstrait « d’agents ».
Comparer Hetzner, OVH et Scaleway
Les noms et tarifs d’offres changent régulièrement ; vérifiez le catalogue au moment de commander plutôt que de figer une référence ancienne.
| Fournisseur | Positionnement | Localisation disponible | Point fort | Point de vigilance |
|---|---|---|---|---|
| Hetzner (lien affilié) | VPS généraliste au prix agressif | Europe | Bon rapport ressources/prix | Support et administration restent à votre charge |
| OVHcloud (lien affilié) | Écosystème français large | France et Europe | Facturation et services familiers en France | Offre équivalente parfois plus chère |
| Scaleway (lien affilié) | Instances et services cloud | France et Europe | Choix de régions françaises | Catalogue plus technique à comparer |
Pour héberger OpenClaw sans besoin réglementaire particulier, Hetzner reste notre choix par défaut. OVHcloud est cohérent si vos domaines, sauvegardes ou processus sont déjà chez OVH. Scaleway convient si une région française et des services cloud complémentaires pèsent davantage que le prix brut.
Le coût réel additionne l’instance, les snapshots, le stockage externe, le trafic éventuellement facturé, le nom de domaine et le temps d’administration. Une petite installation se situe souvent dans une enveloppe d’une dizaine à quelques dizaines d’euros par mois, mais évitez de promettre un montant fixe : le navigateur, les sauvegardes et les API de modèles peuvent dépasser le prix du VPS.
Installer par la voie normale
Sur Linux, l’installateur officiel détecte l’OS, installe une version de Node compatible si nécessaire et lance l’onboarding :
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw --version
openclaw doctor
openclaw gateway status --require-rpc
Le produit recommande Node 26 ; les versions minimales prises en charge sont précisées dans la documentation d’installation. Évitez de passer par pip : OpenClaw n’est pas un paquet Python à importer. Le guide complet d’OpenClaw replace le Gateway, les canaux et les outils dans leur architecture actuelle.
Garder le Gateway privé
Le choix le plus sûr est de conserver le bind loopback puis d’accéder au tableau de bord par Tailscale ou tunnel SSH :
ssh -N -L 18789:127.0.0.1:18789 user@gateway-host
Le navigateur local ouvre ensuite http://127.0.0.1:18789. Cette approche évite d’exposer directement le port du Gateway. Si vous utilisez lan, tailnet ou un reverse proxy, configurez explicitement une authentification par token, mot de passe ou proxy de confiance, puis limitez les origines de la Control UI. N’ouvrez pas 18789 à Internet « pour tester ».
Utiliser Docker seulement s’il apporte une frontière utile
Le chemin officiel part du dépôt OpenClaw et du script fourni :
git clone https://github.com/openclaw/openclaw.git
cd openclaw
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh
L’image officielle provient de ghcr.io/openclaw/openclaw ; un miroir officiel existe aussi sur Docker Hub. Pour la production, épinglez un tag de version au lieu de dépendre durablement de latest. Le script prépare les volumes, l’onboarding et le démarrage Compose. Ne recopiez pas un docker-compose.yml non officiel avec une image inventée. Le guide OpenClaw avec Docker détaille ce parcours.
Prévoir persistance et redémarrage
Une installation supervisée se contrôle avec les commandes du produit :
openclaw gateway status
openclaw gateway restart
openclaw logs --follow
openclaw channels status --probe
Sur un serveur Linux sans session graphique, activez le lingering pour que le service utilisateur survive à la déconnexion :
sudo loginctl enable-linger "$(whoami)"
Sauvegardez ~/.openclaw/openclaw.json, les workspaces et l’état SQLite selon une politique chiffrée. Testez la restauration sur une autre VM. Un snapshot fournisseur facilite un retour rapide, mais ne remplace pas une copie indépendante.
Mettre à jour sans perdre le contrôle
Avant une mise à jour, notez openclaw --version, sauvegardez l’état et lisez les notes de version. Après mise à jour, exécutez :
openclaw doctor
openclaw gateway status --require-rpc
openclaw channels status --probe
openclaw security audit --deep
Conservez un moyen de revenir à la version précédente, surtout avec une image Docker épinglée. La procédure complète est décrite dans OpenClaw en production.
Évaluer la qualité d’un hébergement après une semaine
Ne jugez pas le fournisseur uniquement sur l’absence de panne visible. Relevez les redémarrages du service, le pic de mémoire, l’espace consommé par les logs, la durée des sauvegardes et la latence des tours d’agent. Vérifiez aussi que les canaux se reconnectent après un reboot et que les automations conservent leur prochaine échéance.
Un test simple consiste à redémarrer le VPS pendant une fenêtre prévue, attendre le retour du service supervisé, puis exécuter les probes Gateway et canaux. Lancez ensuite une automation de test sans effet externe et contrôlez son historique. Si le serveur atteint régulièrement sa limite mémoire ou si les sandboxes ralentissent toutes les sessions, augmentez les ressources ou déplacez les outils lourds. Si la capacité reste largement inutilisée, conservez la petite instance : surdimensionner ne compense ni une mauvaise sauvegarde ni une exposition réseau trop large.
Exemple concret
Une petite équipe veut recevoir sur Telegram une veille quotidienne et quelques alertes, sans rendre le tableau de bord public. Elle choisit un VPS européen avec 2 vCPU, 4 Go de RAM et un volume SSD. L’administrateur crée un utilisateur Linux dédié, durcit SSH, installe Tailscale, puis lance l’installateur officiel et openclaw onboard --install-daemon.
La configuration reste à son emplacement canonique : ~/.openclaw/openclaw.json. Le Gateway écoute seulement sur loopback. L’équipe ouvre la Control UI via Tailscale ou un tunnel SSH, puis vérifie le canal avec openclaw channels status --probe. Une automation quotidienne est créée par la CLI OpenClaw et son résultat est livré au canal prévu ; aucun cron système n’est nécessaire.
La validation est reproductible :
openclaw gateway status --require-rpc
openclaw health --json
openclaw channels status --probe
openclaw automations list
openclaw security audit --deep
Le serveur est snapshoté avant chaque mise à jour, tandis qu’une sauvegarde chiffrée indépendante couvre l’état et le workspace. Après un redémarrage du VPS, l’équipe vérifie que le Gateway revient, que Telegram reste connecté et que la prochaine automation est toujours listée. Ce test prouve la persistance réelle, pas seulement le démarrage du processus.
Bonnes pratiques
- Conservez un seul Gateway par machine, sauf besoin d’isolation explicite. Si vous en lancez plusieurs, séparez ports,
OPENCLAW_CONFIG_PATH,OPENCLAW_STATE_DIRet workspaces. - Traitez un Gateway comme une frontière de confiance. Des utilisateurs mutuellement non fiables doivent avoir des Gateway, utilisateurs système ou hôtes séparés.
- Gardez le port sur loopback et préférez Tailscale ou SSH. Une authentification ne rend pas souhaitable une exposition publique inutile.
- N’enregistrez pas les secrets dans un dépôt. Sauvegardez-les chiffrés et contrôlez les permissions du répertoire d’état.
- Surveillez mémoire, disque, redémarrages, santé du Gateway et état des canaux. Les sessions stockées ne prouvent pas qu’un canal est actuellement connecté.
- Épinglez les images Docker en production et utilisez uniquement les registres officiels.
- Testez une restauration et un reboot avant de considérer l’hébergement comme prêt.
La sobriété gagne : une VM correctement sauvegardée, un Gateway privé et une procédure de diagnostic claire sont plus fiables qu’une architecture cloud complexe sans runbook.
Questions fréquentes
Où héberger OpenClaw au meilleur rapport qualité-prix ?
Un VPS Linux européen suffit généralement pour un assistant personnel disponible en continu. Hetzner offre souvent un bon rapport ressources/prix ; OVHcloud ou Scaleway peuvent mieux convenir pour une région française ou un écosystème existant. Comparez surtout la RAM, les sauvegardes et le coût du stockage, pas seulement le prix d’appel.
Docker est-il obligatoire pour héberger OpenClaw ?
Non. Docker est optionnel et sert surtout à isoler le Gateway ou à éviter une installation locale. La voie standard installe OpenClaw puis un service supervisé avec openclaw onboard --install-daemon. Si vous choisissez Docker, utilisez l’image officielle, des volumes persistants et un tag épinglé.
Quelles ressources prévoir pour un serveur OpenClaw ?
Pour un petit usage, 2 vCPU et 4 Go de RAM donnent une marge raisonnable. Un build Docker demande au moins 2 Go selon la documentation. Ajoutez de la mémoire si vous lancez un navigateur, des sandboxes ou des outils lourds, puis dimensionnez à partir des métriques observées.
Faut-il exposer le port 18789 derrière Nginx ?
Pas par défaut. Le schéma le plus sûr garde le Gateway sur loopback et passe par Tailscale ou un tunnel SSH. Si un reverse proxy est nécessaire, activez l’authentification, déclarez précisément les proxies et origines de confiance, terminez TLS et n’acceptez pas aveuglément les en-têtes transférés.
Articles liés
Pour héberger OpenClaw, choisissez d’abord la frontière de confiance et le mode d’accès, puis le fournisseur. Un VPS modeste et privé suffit souvent ; la qualité des sauvegardes, de la supervision et des mises à jour compte davantage qu’un catalogue cloud étendu. Votre serveur choisi, appliquez ensuite la checklist de production.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.