Aller au contenu
Guides

OpenClaw sur Docker

Ce que fait le script d’installation, et ce qu’il ne fait pas

5 min de lecture

Docker est la voie du milieu pour OpenClaw : ni l’installation en une ligne sur votre portable, ni un hébergeur managé, mais une passerelle isolée que l’on peut jeter et reconstruire. En amont, on la qualifie d’optionnelle, et c’est le bon mot. Voici ce que fait le flux officiel, où il pique, et quand il cesse d’en valoir la peine.

Ce que fait vraiment le script d’installation

Le script officiel construit l’image en local ou en récupère une pré-construite, lance l’onboarding, qui demande les clés des fournisseurs et écrit un jeton de passerelle généré dans le fichier .env, puis démarre la passerelle avec Docker Compose. Les images pré-construites sont publiées d’abord sur le GitHub Container Registry, avec un miroir Docker Hub, en variantes slim et navigateur ; une construction locale réclame au moins 6 Go de RAM.

  • Le bac à sable est désactivé par défaut, et la passerelle elle-même n’a pas besoin de tourner dans un conteneur pour qu’il fonctionne.
  • L’interface de contrôle est sur le port 18789 ; vous collez le jeton du fichier .env dans ses réglages.
  • Les canaux s’ajoutent depuis le conteneur CLI : une connexion WhatsApp par QR, ou un jeton de bot pour Telegram ou Discord.

Où ça pique

Trois pièges, tous tirés de la page officielle elle-même. Relancer l’installation avec un shell vide réécrit le fichier .env depuis le shell courant et ses valeurs par défaut, donc changer seulement l’image suppose d’éditer .env et de recréer le conteneur. Un volume home qui recouvre le cache Playwright peut masquer le Chromium embarqué dans l’image, et le navigateur n’est plus trouvé après le passage à une variante navigateur. Et quand une nouvelle image ne peut pas terminer ses migrations de démarrage en sécurité, la passerelle s’arrête au lieu de se déclarer saine, donc une politique de redémarrage montre un conteneur qui redémarre en boucle jusqu’à ce que vous lanciez la commande doctor sur le même état monté.

Rien de tout cela n’est un bug. C’est la forme qu’a l’exploitation d’un service à état dans un conteneur : l’état vit dans des montages, la configuration dans un fichier que le script possède, et les mises à niveau sont votre travail. Notre page sur votre propre serveur explique quand cet échange reste le bon.

Des installations qui se terminent techniquement, mais qui ne sont toujours pas vraiment utilisables.

Quand Docker cesse d’en valoir la peine

Docker gagne sa place quand vous voulez de l’isolation sur une machine que vous exploitez déjà, ou une passerelle reconstructible de zéro. Il cesse de la gagner dès que les questions deviennent celles du maintien : qui la redémarre, qui met l’image à niveau, qui sauvegarde le volume d’état, qui surveille les journaux. OpenClaw hébergé sur Diali, c’est le même runtime quand ces questions ont des réponses : une instance isolée par agent, des mises à jour testées d’abord sur nos propres agents, des sauvegardes, et un tableau de bord à la place d’un fichier compose.

Une courte liste si vous vous lancez

  • Utilisez les noms d’images officiels et épinglez une étiquette de version pour tout ce dont vous dépendez.
  • Conservez le volume d’état, et sauvegardez-le avant chaque changement d’image.
  • Lisez la page de durcissement de la sécurité avant d’exposer la passerelle sur un VPS.
  • Décidez d’avance qui possède la mise à niveau, parce que le conteneur ne le fera pas.

Et quelle que soit la façon de l’exécuter, la facture du modèle a la même taille : ce que coûte vraiment OpenClaw.

Commencer

Arrêtez de lire, construisez le vôtre

Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.