OpenClaw sur Fly.io

Fly.io est la réponse de la documentation pour ceux qui veulent la passerelle sur une machine gérée avec HTTPS et un volume sans faire tourner eux-mêmes une VM : cloner le dépôt, personnaliser la configuration Fly, créer une application et un volume, définir les secrets, déployer, puis créer la configuration par SSH ou via l’interface de contrôle. La partie intéressante est le gabarit, dont chaque ligne répond à une panne que quelqu’un a rencontrée. Voici le chemin, les réglages, la règle des secrets, et la variante privée.

Le chemin rapide

• Clonez le dépôt et choisissez un nom d’application ; créez l’application et un volume d’un gigaoctet dans une région proche de vous, la documentation citant Londres, la Virginie et San José comme choix courants.
• Modifiez la configuration Fly : le fichier suivi est le gabarit public, et une variante durcie sans IP publique est livrée à côté.
• Définissez les secrets : un jeton de passerelle généré en hexadécimal aléatoire, les clés des fournisseurs de modèles, et les jetons des canaux ; la documentation dit de les traiter comme des mots de passe et de préférer les secrets au fichier de configuration pour que les clés en restent absentes.
• Déployez, puis connectez-vous en SSH pour créer la configuration ou utilisez l’interface de contrôle.

Les liaisons hors boucle locale (--bind lan) exigent un chemin d’authentification de passerelle valide.

Les lignes qui comptent

Le processus lance le point d’entrée compilé avec la passerelle liée à l’adresse du réseau local pour que le proxy de Fly puisse l’atteindre, l’option d’autorisation sans configuration pour qu’elle démarre avant qu’une configuration existe, et un port qui doit correspondre au port interne pour les vérifications de santé. La vérification de santé frappe le point d’accès de démarrage, qui admet le trafic une fois le démarrage terminé quel que soit l’état des canaux. La mémoire est de deux gigaoctets parce qu’un demi-gigaoctet est trop petit, le répertoire d’état pointe vers le volume monté pour que l’état survive, et le processus tourne toujours sous l’init de l’image parce que Fly remplace la commande, pas le point d’entrée. Les machines sont réglées pour ne pas s’arrêter automatiquement, avec au moins une en marche.

Secrets et authentification

• Parce que la passerelle se lie au-delà de la boucle locale, un chemin d’authentification valide est obligatoire : un jeton dans la variable de jeton de passerelle, un mot de passe configuré, ou un déploiement à proxy de confiance correctement configuré.
• Les clés de fournisseurs et les jetons de canaux entrent comme secrets et sont lus comme variables d’environnement ; le contrat des secrets permet à la configuration de les référencer plutôt que de les contenir.
• La variante privée ne garde aucune IP publique et c’est la version que la documentation appelle durcie.

OpenClaw sur Docker explique l’image que font tourner ces machines, et Les secrets dans OpenClaw les références qui gardent les clés hors du fichier de configuration.

Face aux autres plateformes

Fly est la plus manuelle des trois pages de plateformes, un fichier de configuration et une CLI, là où OpenClaw sur Railway est un gabarit en un clic avec un volume et quatre variables, et OpenClaw sur Render un plan déclaratif avec un jeton généré.

Sur Diali

Diali est la même idée avec les choix de plateforme déjà faits : une instance isolée, un état persistant, HTTPS, un jeton que vous ne voyez jamais, et des mises à jour déployées pour vous. OpenClaw hébergé sur Diali est l’assistant.

• Une application, un volume, des secrets, un déploiement.
• Se lier au réseau local, faire correspondre le port, vérifier le point d’accès de démarrage.
• Deux gigaoctets ; un demi-gigaoctet est trop petit.