Serveur Linux

Exécutez le Gateway OpenClaw sur n’importe quel serveur Linux ou VPS cloud. Cette page vous aide à choisir un fournisseur, explique le fonctionnement des déploiements cloud et présente les réglages Linux génériques applicables partout.

Choisir un fournisseur

AWS (EC2 / Lightsail / offre gratuite) fonctionne également très bien. Un tutoriel vidéo de la communauté est disponible à l’adresse x.com/techfrenAJ/status/2014934471095812547 (ressource communautaire susceptible de devenir indisponible).

Fonctionnement des configurations cloud

• Le Gateway s’exécute sur le VPS et gère l’état ainsi que l’espace de travail.
• Vous vous connectez depuis votre ordinateur portable ou votre téléphone via l’interface de contrôle ou Tailscale/SSH.
• Considérez le VPS comme la source de référence et sauvegardez régulièrement l’état ainsi que l’espace de travail.
• Configuration sécurisée par défaut : conservez le Gateway sur local loopback et accédez-y au moyen d’un tunnel SSH ou de Tailscale Serve. Si vous le liez à lan ou tailnet, le Gateway exige un secret partagé (gateway.auth.token ou gateway.auth.password), sauf si l’authentification est déléguée à un proxy de confiance.

Pages connexes : Accès distant au Gateway, Portail des plateformes.

Sécuriser d’abord l’accès administrateur

Avant d’installer OpenClaw sur un VPS public, déterminez comment vous souhaitez administrer la machine elle-même.

• Pour un accès administrateur limité au tailnet : installez d’abord Tailscale, connectez le VPS à votre tailnet, vérifiez une seconde session SSH via l’adresse IP Tailscale ou le nom MagicDNS, puis restreignez l’accès SSH public.
• Sans Tailscale : appliquez un renforcement équivalent à votre accès SSH avant d’exposer davantage de services.
• Cette configuration est distincte de l’accès au Gateway. Vous pouvez toujours conserver OpenClaw lié à local loopback et utiliser un tunnel SSH ou Tailscale Serve pour le tableau de bord.

Les options du Gateway propres à Tailscale sont présentées dans Tailscale.

Agent d’entreprise partagé sur un VPS

L’exécution d’un agent unique pour une équipe constitue une configuration valide lorsque tous les utilisateurs se trouvent dans le même périmètre de confiance et que l’agent est exclusivement réservé à un usage professionnel.

• Utilisez un environnement d’exécution dédié (VPS/machine virtuelle/conteneur avec utilisateur et comptes de système d’exploitation dédiés).
• Ne connectez pas cet environnement d’exécution à des comptes Apple/Google personnels ni à des profils personnels de navigateur ou de gestionnaire de mots de passe.
• Si les utilisateurs sont susceptibles d’agir de manière hostile les uns envers les autres, séparez-les par Gateway, hôte ou utilisateur du système d’exploitation.

Détails sur le modèle de sécurité : Sécurité.

Utilisation de nœuds avec un VPS

Vous pouvez conserver le Gateway dans le cloud et associer des nœuds sur vos appareils locaux (Mac/iOS/Android/sans interface graphique). Les nœuds fournissent des fonctionnalités locales d’écran, de caméra, de canevas et system.run, tandis que le Gateway reste dans le cloud.

Documentation : Nœuds, CLI des nœuds.

Optimisation du démarrage pour les petites machines virtuelles et les hôtes ARM

Si les commandes CLI semblent lentes sur des machines virtuelles peu puissantes (ou des hôtes ARM), activez le cache de compilation des modules de Node :

grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cachemkdir -p /var/tmp/openclaw-compile-cacheexport OPENCLAW_NO_RESPAWN=1EOFsource ~/.bashrc

• NODE_COMPILE_CACHE accélère le démarrage des commandes répétées ; la première exécution initialise le cache.
• OPENCLAW_NO_RESPAWN=1 maintient les redémarrages courants du Gateway dans le même processus, ce qui évite des transferts de processus supplémentaires et simplifie le suivi des PID sur les petits hôtes.
• Pour les particularités du Raspberry Pi, consultez Raspberry Pi.

Liste de contrôle facultative pour l’optimisation de systemd

Pour les hôtes de machines virtuelles utilisant systemd, envisagez les réglages suivants :

• Variables d’environnement du service pour un chemin de démarrage stable : OPENCLAW_NO_RESPAWN=1 et NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
• Comportement de redémarrage explicite : Restart=always, RestartSec=2, TimeoutStartSec=90
• Disques SSD pour les chemins d’état et de cache afin de réduire les pénalités de démarrage à froid liées aux entrées-sorties aléatoires.

La procédure standard openclaw onboard --install-daemon installe une unité utilisateur systemd ; modifiez-la avec :

systemctl --user edit openclaw-gateway.service

[Service]Environment=OPENCLAW_NO_RESPAWN=1Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cacheRestart=alwaysRestartSec=2TimeoutStartSec=90

Si vous avez délibérément installé une unité système à la place, modifiez-la avec sudo systemctl edit openclaw-gateway.service.

Comment les stratégies Restart= facilitent la récupération automatisée : systemd peut automatiser la récupération des services.

Pour en savoir plus sur le comportement Linux en cas d’épuisement de la mémoire, la sélection des processus enfants à interrompre et le diagnostic de exit 137, consultez Pression mémoire et interruptions OOM sous Linux.

Pages connexes

• Vue d’ensemble de l’installation
• DigitalOcean
• Fly.io
• Hetzner