Objectif : Gateway OpenClaw exécuté sur une machine Fly.io avec stockage persistant, HTTPS automatique et accès Discord/canal.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Ce dont vous avez besoin
- CLI flyctl installée
- Compte Fly.io (l’offre gratuite fonctionne)
- Authentification de modèle : clé d’API pour le fournisseur de modèles choisi
- Identifiants de canal : jeton de bot Discord, jeton Telegram, etc.
Parcours rapide pour débuter
- Cloner le dépôt → personnaliser
fly.toml - Créer l’application + le volume → définir les secrets
- Déployer avec
fly deploy - Se connecter en SSH pour créer la configuration ou utiliser l’interface de contrôle
Créer l’application Fly
lhr (Londres), iad (Virginie), sjc (San Jose).Configurer fly.toml
Modifiez L’image Docker OpenClaw utilise
fly.toml pour qu’il corresponde au nom de votre application et à vos besoins.Note de sécurité : La configuration par défaut expose une URL publique. Pour un déploiement renforcé sans IP publique, consultez Déploiement privé ou utilisez deploy/fly.private.toml.tini comme point d’entrée. Les commandes de processus Fly remplacent le CMD Docker sans remplacer l’ENTRYPOINT, donc le processus s’exécute toujours sous tini.Paramètres clés :| Paramètre | Pourquoi |
|---|---|
--bind lan | Lie à 0.0.0.0 afin que le proxy de Fly puisse atteindre le Gateway |
--allow-unconfigured | Démarre sans fichier de configuration (vous en créerez un ensuite) |
internal_port = 3000 | Doit correspondre à --port 3000 (ou OPENCLAW_GATEWAY_PORT) pour les contrôles de santé Fly |
memory = "2048mb" | 512 Mo est insuffisant ; 2 Go recommandés |
OPENCLAW_STATE_DIR = "/data" | Persiste l’état sur le volume |
Définir les secrets
- Les liaisons non loopback (
--bind lan) nécessitent un chemin d’authentification Gateway valide. Cet exemple Fly.io utiliseOPENCLAW_GATEWAY_TOKEN, maisgateway.auth.passwordou un déploiementtrusted-proxynon loopback correctement configuré satisfait également l’exigence. - Traitez ces jetons comme des mots de passe.
- Préférez les variables d’environnement au fichier de configuration pour toutes les clés d’API et tous les jetons. Cela évite que les secrets se retrouvent dans
openclaw.json, où ils pourraient être accidentellement exposés ou journalisés.
Déployer
Créer le fichier de configuration
Connectez-vous à la machine en SSH pour créer une configuration correcte :Créez le répertoire et le fichier de configuration :Note : Avec
OPENCLAW_STATE_DIR=/data, le chemin de configuration est /data/openclaw.json.Note : Remplacez https://my-openclaw.fly.dev par l’origine réelle de votre application Fly. Le démarrage du Gateway initialise les origines locales de l’interface de contrôle à partir des valeurs d’exécution --bind et --port, afin que le premier démarrage puisse continuer avant que la configuration n’existe, mais l’accès via navigateur à travers Fly nécessite toujours que l’origine HTTPS exacte soit listée dans gateway.controlUi.allowedOrigins.Note : Le jeton Discord peut provenir de l’une des deux sources suivantes :- Variable d’environnement :
DISCORD_BOT_TOKEN(recommandé pour les secrets) - Fichier de configuration :
channels.discord.token
DISCORD_BOT_TOKEN.Redémarrez pour appliquer :Accéder au Gateway
Interface de contrôle
Ouvrez dans un navigateur :https://my-openclaw.fly.dev/Authentifiez-vous avec le secret partagé configuré. Ce guide utilise le jeton Gateway de OPENCLAW_GATEWAY_TOKEN ; si vous êtes passé à l’authentification par mot de passe, utilisez plutôt ce mot de passe.Journaux
Console SSH
Dépannage
« L’application n’écoute pas sur l’adresse attendue »
Le Gateway est lié à127.0.0.1 au lieu de 0.0.0.0.
Correctif : Ajoutez --bind lan à votre commande de processus dans fly.toml.
Échec des contrôles de santé / connexion refusée
Fly ne peut pas atteindre le Gateway sur le port configuré. Correctif : Assurez-vous queinternal_port correspond au port du Gateway (définissez --port 3000 ou OPENCLAW_GATEWAY_PORT=3000).
Problèmes de mémoire / OOM
Le conteneur redémarre en boucle ou est tué. Signes :SIGABRT, v8::internal::Runtime_AllocateInYoungGeneration ou redémarrages silencieux.
Correctif : Augmentez la mémoire dans fly.toml :
Problèmes de verrou du Gateway
Le Gateway refuse de démarrer avec des erreurs « déjà en cours d’exécution ». Cela se produit lorsque le conteneur redémarre mais que le fichier de verrou PID persiste sur le volume. Correctif : Supprimez le fichier de verrou :/data/gateway.*.lock (pas dans un sous-répertoire).
La configuration n’est pas lue
--allow-unconfigured contourne seulement la garde de démarrage. Il ne crée ni ne répare /data/openclaw.json, assurez-vous donc que votre vraie configuration existe et inclut gateway.mode="local" lorsque vous voulez un démarrage normal du Gateway local.
Vérifiez que la configuration existe :
Écrire la configuration via SSH
La commandefly ssh console -C ne prend pas en charge la redirection shell. Pour écrire un fichier de configuration :
fly sftp peut échouer si le fichier existe déjà. Supprimez-le d’abord :
L’état ne persiste pas
Si vous perdez les profils d’authentification, l’état des canaux/fournisseurs ou les sessions après un redémarrage, le répertoire d’état écrit dans le système de fichiers du conteneur. Correctif : Assurez-vous queOPENCLAW_STATE_DIR=/data est défini dans fly.toml et redéployez.
Mises à jour
Mettre à jour la commande de la machine
Si vous devez changer la commande de démarrage sans redéploiement complet :fly deploy, la commande de la machine peut revenir à celle définie dans fly.toml. Si vous avez effectué des changements manuels, réappliquez-les après le déploiement.
Déploiement privé (renforcé)
Par défaut, Fly alloue des IP publiques, ce qui rend votre Gateway accessible àhttps://your-app.fly.dev. C’est pratique, mais cela signifie que votre déploiement est découvrable par les scanners Internet (Shodan, Censys, etc.).
Pour un déploiement renforcé avec aucune exposition publique, utilisez le modèle privé.
Quand utiliser un déploiement privé
- Vous effectuez uniquement des appels/messages sortants (aucun Webhook entrant)
- Vous utilisez des tunnels ngrok ou Tailscale pour tous les rappels de Webhook
- Vous accédez au Gateway via SSH, proxy ou WireGuard au lieu d’un navigateur
- Vous voulez que le déploiement soit caché des scanners Internet
Configuration
Utilisezdeploy/fly.private.toml au lieu de la configuration standard :
fly ips list ne devrait afficher qu’une IP de type private :
Accéder à un déploiement privé
Comme il n’y a pas d’URL publique, utilisez l’une de ces méthodes : Option 1 : Proxy local (le plus simple)Webhooks avec un déploiement privé
Si vous avez besoin de callbacks Webhook (Twilio, Telnyx, etc.) sans exposition publique :- Tunnel ngrok - Exécutez ngrok dans le conteneur ou comme sidecar
- Tailscale Funnel - Exposez des chemins spécifiques via Tailscale
- Sortant uniquement - Certains fournisseurs (Twilio) fonctionnent correctement pour les appels sortants sans Webhook
webhookSecurity.allowedHosts sur le nom d’hôte public du tunnel afin que les en-têtes d’hôte transférés soient acceptés.
Avantages en matière de sécurité
| Aspect | Public | Privé |
|---|---|---|
| Scanners Internet | Découvrable | Masqué |
| Attaques directes | Possibles | Bloquées |
| Accès à l’interface de contrôle | Navigateur | Proxy/VPN |
| Livraison Webhook | Directe | Via tunnel |
Notes
- Fly.io utilise une architecture x86 (pas ARM)
- Le Dockerfile est compatible avec les deux architectures
- Pour l’intégration WhatsApp/Telegram, utilisez
fly ssh console - Les données persistantes se trouvent sur le volume à
/data - Signal nécessite Java + signal-cli ; utilisez une image personnalisée et conservez au moins 2 Go de mémoire.
Coût
Avec la configuration recommandée (shared-cpu-2x, 2 Go de RAM) :
- ~10 à 15 $/mois selon l’utilisation
- L’offre gratuite inclut une certaine allocation
Étapes suivantes
- Configurer les canaux de messagerie : Canaux
- Configurer le Gateway : Configuration du Gateway
- Maintenir OpenClaw à jour : Mise à jour