OpenClaw en 2026 : installation Docker, durcissement production, proxy inverse, dépannage — et workflow sur Mac distant

OpenClaw est une pile d’assistant IA self-hosted : une passerelle (plan de contrôle WebSocket, URL type ws://127.0.0.1:18789), une interface de contrôle dans le navigateur, une CLI, des canaux optionnels (Telegram, Slack, etc.) et l’exécution d’outils sur l’hôte ou en sandbox. En 2026, deux schémas se croisent :

• Passerelle sur Linux/VPS — plan de contrôle toujours actif à côté de vos API ; accès distant par SSH ou Tailscale.
• Exécution lourde sur Mac distant — builds Xcode, binaires macOS, scripts longs et agents sans laisser un portable ouvert toute la nuit.

Ici, on reste tutoriel : commandes copiables, ports explicites, symptômes classiques en un coup d’œil — pas de « tendance IA » creuse.

Voie CLI recommandée (README officiel) :

npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw gateway --port 18789 --verbose

Ouvrez http://127.0.0.1:18789/ pour l’UI. Après mise à jour : openclaw doctor.

Voie Docker (documentation install/docker — à la racine du clone) :

git clone https://github.com/openclaw/openclaw.git
cd openclaw
./scripts/docker/setup.sh

Pour éviter la build locale :

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

Sandbox côté passerelle (optionnel) : export OPENCLAW_SANDBOX=1 avant le script, comme décrit dans la doc Docker.

Bind. La configuration utilise gateway.bind avec des valeurs comme lan, loopback, tailnet, auto, custom — pas des alias hôte type 0.0.0.0 dans ce champ. Sous Docker, le script fixe par défaut OPENCLAW_GATEWAY_BIND=lan pour que 127.0.0.1:18789 sur l’hôte fonctionne avec le port publié. Avec Tailscale Serve/Funnel, la doc exige en général loopback pour gateway.bind.

Jeton et UI. L’assistant Docker écrit un jeton de passerelle dans .env ; collez-le dans les réglages de l’UI. Traitez-le comme un secret racine du plan de contrôle.

Canaux et DM. Les DM entrants sont des entrées non fiables ; les politiques d’appairage par défaut bloquent les expéditeurs inconnus jusqu’à openclaw pairing approve …. Lancez openclaw doctor pour détecter des réglages risqués.

Sandbox agents. Pour des sessions de groupe plus sûres, la doc propose agents.defaults.sandbox.mode: "non-main" (référence sandboxing). Distinct du « passerelle dans Docker », mais souvent le même moteur Docker pour l’isolement.

Sortie réseau. Limitez la sortie au pare-feu si les agents ne doivent pas joindre Internet arbitrairement ; combinez avec des politiques allow/deny d’outils en configuration.

La documentation met en avant Tailscale Serve/Funnel et les tunnels SSH. Avec un proxy classique, terminez le TLS sur Nginx/Caddy et proxifiez vers 127.0.0.1:18789 (HTTP + WebSocket pour l’UI).

Caddy (exemple) — préserver l’en-tête Host et laisser Caddy gérer l’upgrade WebSocket :

claw.example.com {
  reverse_proxy 127.0.0.1:18789
}

Nginx — ajoutez Upgrade et Connection pour les chemins WebSocket utilisés par l’UI ; détaillez les locations exactes selon docs.openclaw.ai/web.

Checklist HTTPS : certificat valide ; seul le 443 (ou équivalent) exposé publiquement ; limitation de débit ou liste d’IP pour les routes sensibles ; rotation du jeton documentée ; test curl -fsS https://claw.example.com/healthz via le proxy.

Pattern pour une capacité Mac mini louée ou dédiée : le Mac est l’îlot d’exécution macOS ; les secrets restent sur la machine ; vous pilotez par SSH (voir le guide SSH/VNC première connexion).

1. Provisionnement — SSH, Docker Desktop ou Colima, ou Node + CLI globale comme en section 3.
2. OpenClaw — soit openclaw onboard --install-daemon, soit clone + ./scripts/docker/setup.sh avec volumes persistants pour config et workspace.
3. Batch — cron ou launchd lance votre script de build ; les artefacts vont sous ~/.openclaw/workspace ou un répertoire CI dédié.
4. Notification — webhook Slack/Telegram en fin de script ; les sessions agent peuvent lire des journaux structurés.
5. Vérification — depuis votre poste : ssh mac 'curl -fsS http://127.0.0.1:18789/healthz' ; tunnel UI : ssh -L 18789:127.0.0.1:18789 mac puis http://127.0.0.1:18789/.

Résultat attendu : builds et files d’agents terminent sans supervision ; la passerelle reste saine ; vous déboguez par logs et UI occasionnelle sans exposer 18789 sur Internet.

Faut-il Docker si je veux seulement des agents sandboxés ? Le sandbox peut utiliser Docker pendant que la passerelle tourne en natif — voir la doc Sandboxing vs Docker (optionnel).

Où est l’état ? Compose monte OPENCLAW_CONFIG_DIR et le workspace documentés dans la page Docker ; sauvegardez comme tout dépôt de secrets + fichiers produits par les agents.

Rien n’écoute : première étape ? docker compose ps ou openclaw doctor, puis curl sur /healthz.

Mettre OpenClaw en production, c’est surtout : bon chemin d’install (onboard CLI vs ./scripts/docker/setup.sh), port 18789 stable, bind cohérent avec votre mode d’exposition, et défense en profondeur (jeton, appairage DM, sandbox non-main possible, pare-feu). Ajoutez un Mac distant lorsque macOS ou des agents longue durée exigent du matériel dédié.

Pour une capacité Mac 24/7 prévisible — fermes de build, files d’agents, scripts nocturnes — parcourez Tarifs et Achat, et gardez le centre d’aide pour l’accès et la facturation.