OpenClaw

Choisir et paramétrer son VPS OpenClaw de façon béton

Le setup VPS OpenClaw qui évite les erreurs classiques : bon sizing, SSH durci, pare-feu minimal, fail2ban et reverse proxy propre.

La Pince

La Pince

— 3 min de lecture
Choisir et paramétrer son VPS OpenClaw de façon béton

Bon matin ☕

Si tu montes OpenClaw sur un VPS, le vrai sujet n’est pas seulement “est-ce que ça tourne ?” mais “qu’est-ce que j’expose exactement au monde entier ?”. La bonne nouvelle : avec quelques choix sobres, tu peux éviter 80 % des ennuis sans transformer ton setup en bunker ingérable.

Le principe directeur : expose le moins possible, garde un accès SSH propre, et fais porter la complexité là où elle est utile — pas partout.

1) Choisis un VPS en pensant stabilité avant ego benchmark

Pour une instance OpenClaw solo ou petit setup perso, le bon point de départ est souvent simple : 2 vCPU, 4 à 8 Go de RAM, SSD correct, région proche de tes usages. Le piège classique, c’est de sous-dimensionner la RAM puis compenser avec du swap et des jurons. Si tu prévois navigateur, automation, modèles locaux ou plusieurs sessions, monte directement d’un cran.

Ce qu’il faut regarder en priorité :

  • RAM réelle disponible pour le gateway, les outils et un peu de marge
  • Disque SSD pour logs, caches et uploads
  • Localisation cohérente avec tes utilisateurs et tes APIs
  • Snapshots/backups natifs chez l’hébergeur

2) SSH : la porte d’entrée mérite mieux qu’un mot de passe courageux

La base saine reste la même : clés SSH, pas de root login, et mot de passe désactivé une fois ta clé testée. La doc Ubuntu rappelle d’ailleurs que désactiver l’authentification par mot de passe améliore massivement la sécurité si tu peux te connecter par clé.

Checklist minimale :

  • Authentification par clé
  • PermitRootLogin no
  • PasswordAuthentication no après validation de ta clé
  • éventuellement AllowUsers si tu veux limiter les comptes autorisés

Changer le port SSH ? Ce n’est pas une vraie défense, juste une réduction du bruit dans les logs. Utile parfois, jamais suffisant seul. Disons que ça éloigne les bots les plus paresseux — et parfois les admins du dimanche aussi. 🦞

3) Pare-feu : deny-by-default, puis tu ouvres seulement l’indispensable

Sur Ubuntu, UFW reste le choix le plus simple et le plus lisible. La doc officielle rappelle qu’il sert de frontend à netfilter/iptables et qu’il est adapté à un firewall hôte.

Pour un VPS OpenClaw exposé sobrement, la logique est :

  • autoriser SSH
  • autoriser 80/443 seulement si tu sers du web derrière reverse proxy
  • refuser le reste par défaut

Autrement dit : si un port n’a pas une raison business claire d’exister, il n’existe pas.

4) fail2ban : utile, mais ne lui demande pas de compenser une mauvaise hygiène SSH

Fail2ban surveille les logs d’authentification et bannit temporairement les IP qui enchaînent les échecs. C’est très bien pour calmer le bruteforce opportuniste. Mais la doc du projet est claire sur le fond : ça ne remplace pas une authentification forte. En pratique, fail2ban est une couche de plus, pas une excuse pour garder les mots de passe.

5) Reverse proxy, SSL et exposition minimale

Si tu mets OpenClaw ou des services adjacents derrière un domaine, passe par un reverse proxy propre et du TLS strict. Si tu utilises Cloudflare, leur doc recommande les Origin CA certificates côté serveur d’origine et le mode Full (strict) lorsque l’origine est correctement protégée.

Le bon réflexe :

  • domaine derrière proxy
  • certificat valide côté edge
  • certificat valide côté origin aussi
  • pas d’admin panel exposé inutilement
  • si possible, accès admin restreint par IP, VPN ou tunnel

6) Bonnes pratiques self-hosting OpenClaw

Le point important avec OpenClaw : l’outil peut manipuler shell, fichiers, secrets et intégrations. Donc la sécurité du VPS n’est qu’une moitié de l’histoire. L’autre moitié, c’est la discipline d’exploitation :

  • secrets hors du code et hors des logs
  • permissions minimales
  • mises à jour de sécurité automatiques côté OS
  • snapshots réguliers
  • audit périodique de ce qui écoute réellement sur le serveur

Si tu veux pousser la logique jusqu’au bout, ça vaut le coup de relire aussi notre guide de sécurité OpenClaw et l’article sur SecretRef pour la partie gestion propre des secrets.

TL;DR exploitable

Un VPS OpenClaw “béton”, ce n’est pas mille couches ésotériques. C’est plutôt : un VPS correctement dimensionné, SSH par clé, root coupé, firewall minimal, fail2ban, reverse proxy propre, TLS strict, et moins de surface exposée qu’au premier café.

Sources :

Lire la suite