OpenClaw 24 h/24 sur un VPS : une installation sûre

Sur un portable, OpenClaw se tait dès que l'écran se rabat : les messages WhatsApp s'accumulent, les tâches planifiées attendent votre retour. Sur un serveur, il continue de répondre. Le hic, c'est que la passerelle n'est pas un widget de chat. Elle détient les identifiants de vos canaux et, tant que vous n'activez pas de sandbox, exécute ses outils directement sur l'hôte. La déplacer sur une machine toujours allumée n'a d'intérêt que si le modèle de sécurité déménage avec elle.

Ce guide s'en charge en une vingtaine de minutes sur un VPS Ubuntu 24.04 tout neuf.

Dernière vérification le 2026-10-04 avec OpenClaw 2026.9.8 (npm), Node 24.21 LTS et Ubuntu 24.04.

Ce qu'il vous faut

• Un VPS Linux. Nous utilisons notre offre AI-Agent : 4 vCPU, 4 Go de RAM, 40 Go de disque, 10 $ par mois. La documentation OpenClaw parle de 6 Go de RAM, mais c'est pour construire leur image Docker depuis les sources ; le paquet npm n'a besoin d'aucun build.
• Une clé API chez votre fournisseur de modèles, et les comptes de messagerie à connecter.
• Une clé SSH sur votre portable. Si vous n'en avez pas encore : connexion par clé SSH.

Une offre en NAT convient ici, et colle même plutôt mieux. La passerelle n'a jamais besoin d'un port entrant ouvert : WhatsApp, Discord et Telegram (long polling par défaut) se connectent vers l'extérieur, et vous atteignez le tableau de bord par SSH. Prenez une IPv4 dédiée seulement si un canal dont vous avez besoin livre par webhook, ou si vous prévoyez un reverse proxy public.

1. Un utilisateur qui n'est pas root

OpenClaw exécute ses outils sous l'utilisateur propriétaire de la passerelle. Si c'est root, chaque commande qu'un modèle perdu ou manipulé par injection de prompt décide de lancer tourne aussi en root. La documentation OpenClaw qualifie l'exécution en root de dangereuse et non prise en charge. Créez un utilisateur dédié, sans sudo :

# en root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # la clé ajoutée à la commande
loginctl enable-linger claw

La dernière ligne compte plus qu'il n'y paraît. OpenClaw installe un service systemd utilisateur, et sans lingering ce service s'arrête quand vous vous déconnectez. C'est le « ça marchait hier » le plus courant sur un serveur.

2. Node 24 et OpenClaw

OpenClaw 2026.9.8 exige Node >=24.16.0 <25 ou >=26.1.0. Le paquet nodejs d'Ubuntu est plus ancien, on prend donc la 24 LTS chez NodeSource :

# en root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 ou plus récent
npm install -g openclaw@latest
openclaw --version

La commande officielle en une ligne (curl -fsSL https://openclaw.ai/install.sh | bash) fonctionne aussi et installe Node pour vous. Sur un serveur, nous préférons les deux étapes explicites : on voit ce qui atterrit où, et le binaire se retrouve dans /usr/bin plutôt que dans un dossier personnel où l'agent peut écrire.

3. L'onboarding avec l'utilisateur de l'agent

Connectez-vous en tant que claw par SSH, pas avec su. Seule une vraie connexion démarre le gestionnaire systemd utilisateur dont le service a besoin :

# depuis votre portable (offre NAT : ajoutez -p <votre port SSH>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

L'assistant vérifie l'accès au modèle, écrit ~/.openclaw/openclaw.json, génère un jeton de passerelle et installe le service. Si systemctl --user se plaint du bus, faites export XDG_RUNTIME_DIR=/run/user/$(id -u) et recommencez.

Ensuite, verrouillez les fichiers. La recommandation d'OpenClaw lui-même : 700 sur le dossier d'état et 600 sur la configuration :

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix applique la partie sûre des corrections : permissions plus strictes et listes d'autorisation à la place des politiques de groupe ouvertes. Il ne change pas l'adresse d'écoute et ne pose aucun pare-feu ; l'exposition réseau reste votre affaire.

4. Gardez la passerelle sur loopback

La passerelle sert son API WebSocket et le tableau de bord sur un seul port, 18789, lié à 127.0.0.1 par défaut. Laissez-la là. Une configuration minimale qui l'écrit noir sur blanc :

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

Générez le jeton avec openssl rand -hex 32 ou openclaw doctor --generate-gateway-token. La passerelle refuse les jetons vides et les valeurs d'exemple, et l'audit avertit en dessous de 24 caractères.

À ne pas faire : passer bind à "lan" et ouvrir le port. La documentation est sans détour : ne jamais exposer la passerelle sans authentification sur 0.0.0.0, et ne pas rediriger le port largement même avec un jeton. Quiconque obtient ce jeton devient opérateur d'un processus capable d'exécuter des commandes sur votre serveur.

Côté pare-feu, autorisez SSH et rien d'autre :

# en root
ufw allow OpenSSH
ufw enable
ufw status verbose

Sur nos offres NAT, le tableau de bord affiche un port SSH externe, mais à l'intérieur du serveur sshd écoute toujours sur 22. Autorisez OpenSSH (port 22), pas le numéro de port externe, sinon ufw enable vous enferme dehors. Plus de détails dans le guide UFW.

5. Accéder au tableau de bord par SSH

Depuis votre portable, ouvrez un tunnel et laissez-le tourner :

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# offre NAT : ssh -N -p <votre port SSH> -L 18789:127.0.0.1:18789 claw@<host>

Ouvrez http://127.0.0.1:18789/ et collez le jeton de la passerelle. Le sshd par défaut d'Ubuntu autorise la redirection locale ; si vous l'avez durci, AllowTcpForwarding local est le réglage qui permet -L tout en bloquant les redirections distantes. Si le tunnel échoue avec administratively prohibited, c'est cette ligne qu'il faut vérifier.

Un tailnet fonctionne aussi : Tailscale Serve garde la passerelle sur loopback et gère l'accès. Les deux conviennent. Un port public, non.

6. Appairage, sandbox, et qui peut lui parler

Les canaux de messagerie sont l'autre porte d'entrée. Par défaut, les canaux avec messages privés font d'abord appairer les expéditeurs inconnus ; vous validez depuis le serveur :

openclaw pairing approve <channel> <code>

Dans les groupes, exigez une mention pour que l'agent ne réponde pas à chaque message du salon. La configuration durcie d'OpenClaw utilise dmPolicy: "pairing" et groups: { "*": { requireMention: true } } par canal.

Deux réserves honnêtes. D'abord, l'appairage contrôle qui peut déclencher un tour, pas ce qui finit dans le contexte du modèle : un message transféré ou une page web récupérée peut encore orienter un tour que vous avez lancé. Ensuite, les outils de la session principale tournent sur l'hôte tant que vous n'activez pas de sandbox (agents.defaults.sandbox.mode: "non-main" isole tout sauf votre propre session principale). La sandbox est désactivée par défaut et son backend par défaut est Docker : installez donc Docker avant de l'activer, voir Docker sur un VPS. Si des personnes à qui vous ne faites pas confiance partagent un canal avec le bot, utilisez une passerelle séparée, idéalement sur un serveur séparé.

7. Mises à jour et sauvegardes

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

~/.openclaw contient la configuration, les identifiants des canaux (session WhatsApp comprise), les profils d'authentification des modèles et les transcriptions de sessions. Le perdre, c'est tout réappairer ; le voir fuiter, c'est laisser quelqu'un d'autre être vous sur WhatsApp. Sauvegardez-le et gardez la copie ailleurs que sur le serveur : récupérez-la avec scp ou utilisez restic avec chiffrement.

Liste de contrôle

Où se place EQVPS

Beaucoup d'hébergeurs savent faire tourner un processus Node. Ce que nous ajoutons : le paiement en crypto sans KYC, une offre NAT taillée pour une passerelle uniquement sur loopback, et un serveur MCP que votre agent peut utiliser pour gérer ses propres serveurs. Si vous y connectez OpenClaw, lisez d'abord les garde-fous MCP : un jeton qui peut commander des serveurs mérite le même soin que le jeton de la passerelle. Pour une vue plus large des agents sur un VPS, voyez le guide des agents IA.

Notre avis : ces 20 minutes font la différence entre un assistant et un shell ouvert avec une interface de chat. Faites au moins les étapes 1, 4 et 5, même si vous sautez le reste.