OpenClaw sur exe.dev

exe.dev vend une VM Linux bon marché toujours allumée avec un proxy HTTPS devant, et la documentation d’OpenClaw s’en sert pour une passerelle joignable à un nom public sans faire tourner son propre VPS. Il y a deux chemins : un chemin débutant où l’agent d’exe.dev, Shelley, installe tout à partir d’un prompt, et un chemin manuel par nginx. Voici les deux, la règle d’en-têtes que la documentation qualifie de risque de durcissement, les réglages d’origine et de proxy, la façon d’atteindre l’interface de contrôle et d’approuver les appareils, le schéma de correctif de configuration pour les canaux, et la mise à jour.

Les deux chemins

• Chemin débutant : ouvrez le lien OpenClaw d’exe.new, renseignez votre clé ou jeton d’authentification, cliquez sur le bouton d’agent à côté de votre VM, attendez que Shelley termine le provisionnement, ouvrez l’adresse HTTPS publique de la VM, authentifiez-vous avec le secret partagé, et approuvez les demandes d’appairage d’appareils en attente depuis le shell.
• Le prompt pour Shelley fourni par la documentation demande une intégration non interactive avec acceptation du risque, un relais nginx du port par défaut de la passerelle vers l’emplacement racine avec prise en charge des WebSockets, l’origine autorisée fixée à l’origine HTTPS publique exacte, les proxys de confiance fixés à la boucle locale parce que nginx écrase l’en-tête forwarded-for, l’appairage par les commandes d’appareils, et une vérification de santé qui affiche OK.
• Chemin manuel : créez la VM, gardez-la avec état parce que la configuration, les magasins d’authentification SQLite partagés et par agent, les sessions, l’état des canaux et des fournisseurs et l’espace de travail vivent tous sous le répertoire d’état, installez les prérequis et lancez le script d’installation.
• Le site nginx écoute sur le port 80 et sur le port 8000, qu’exe.dev transfère vers HTTPS, et relaie vers la passerelle avec HTTP 1.1, les en-têtes de mise à niveau et de connexion pour les WebSockets, les en-têtes de proxy standard, et des délais de lecture et d’envoi d’une journée pour les connexions de longue durée.

Écrasez les en-têtes de transfert au lieu de préserver les chaînes fournies par le client. OpenClaw ne fait confiance aux métadonnées d’IP transférées que depuis des proxys explicitement configurés, et les chaînes X-Forwarded-For par ajout sont traitées comme un risque de durcissement.

Origine, proxy, authentification

Fixez les origines autorisées de l’interface de contrôle à l’origine publique exacte et les proxys de confiance à la seule boucle locale, les deux en JSON strict, puis redémarrez. La vérification d’origine du navigateur échoue fermée pour les noms d’hôte publics, et la liste des proxys laisse OpenClaw utiliser la valeur forwarded-for écrasée par nginx au lieu de traiter chaque requête comme venant du proxy en boucle locale ; gardez cette liste limitée aux proxys que vous contrôlez. Le guide utilise l’authentification par jeton : affichez le jeton configuré depuis un terminal interactif avec la commande d’affichage du jeton, générez-en un avec l’option de doctor si aucun n’est configuré et redémarrez, ou passez le mode d’authentification à un mot de passe tenu dans la configuration ou une variable d’environnement. Approuvez les appareils avec les commandes de liste et d’approbation des appareils, et en cas de doute laissez Shelley le faire depuis le navigateur.

Canaux et mises à jour

• Pour les hôtes distants, la documentation préfère un seul appel de correctif de configuration à de nombreux réglages unitaires : gardez les vrais jetons dans l’environnement de la VM ou le fichier d’environnement du répertoire d’état, ne mettez que des références de secrets dans la configuration, écrivez un fichier de correctif localement, envoyez-le par SSH d’abord en simulation, puis appliquez-le et redémarrez.
• Le correctif d’exemple déclare un fournisseur de secrets adossé à l’environnement, active Slack en mode socket avec les jetons de bot et d’application comme références de secrets, une politique de groupe ouverte et sans mention obligatoire, active Discord avec son jeton en référence, les messages privés désactivés et une politique de groupe par liste d’autorisation, et fixe un modèle principal avec un paramètre de mode rapide ; une option de remplacement de chemin fait qu’une liste d’autorisation imbriquée devient exactement la valeur du correctif.
• exe.dev gère l’authentification de l’accès distant, en transférant le trafic du port 8000 vers le nom HTTPS public avec une authentification par courriel par défaut, et la mise à jour est la commande de mise à jour ordinaire.

L’accès distant à OpenClaw couvre les schémas de proxy et d’origine que cette recette suit, et OpenClaw derrière Cloudflare l’autre façade HTTPS courante pour une passerelle autogérée.

Quand le choisir

Elle convient à quelqu’un qui veut un nom HTTPS public stable et un agent qui fait la plomberie, et qui accepte que la VM, son répertoire d’état et ses mises à jour restent à sa charge. La passerelle OpenClaw expliquée est le processus derrière nginx, et Diali face à votre propre serveur pèse l’hébergement autogéré face à un hébergement géré.

Sur Diali

Sur Diali, les règles de proxy, d’origine et d’en-têtes sont à notre charge, réglées une fois pour chaque instance, le répertoire d’état vit sur un volume persistant, et les mises à jour arrivent avec le train de releases plutôt que par une commande de mise à jour. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière.

• Un prompt à Shelley ou un site nginx.
• Origine exacte, proxy en boucle locale, en-têtes écrasés.
• Secrets dans l’environnement, références dans la configuration, un seul correctif.