Fly.io

Objectif : Gateway OpenClaw exécuté sur une machine Fly.io avec stockage persistant, HTTPS automatique et accès à Discord/aux canaux.

Ce dont vous avez besoin

• CLI flyctl installée
• Compte Fly.io (l’offre gratuite convient)
• Authentification du modèle : clé API pour le fournisseur de modèle choisi
• Identifiants du canal : jeton de bot Discord, jeton Telegram, etc.

Parcours rapide pour débuter

1. Clonez le dépôt, personnalisez fly.toml
2. Créez l’application et le volume, définissez les secrets
3. Déployez avec fly deploy
4. Connectez-vous en SSH pour créer la configuration, ou utilisez l’interface de contrôle

git clone https://github.com/openclaw/openclaw.gitcd openclaw # choisissez votre propre nomfly apps create my-openclaw # 1 Go suffit généralementfly volumes create openclaw_data --size 1 --region iad

app = "my-openclaw"  # nom de votre applicationprimary_region = "iad" [build]  dockerfile = "Dockerfile" [env]  NODE_ENV = "production"  OPENCLAW_PREFER_PNPM = "1"  OPENCLAW_STATE_DIR = "/data"  NODE_OPTIONS = "--max-old-space-size=1536" [processes]  app = "node dist/index.js gateway --allow-unconfigured --port 3000 --bind lan" [http_service]  internal_port = 3000  force_https = true  auto_stop_machines = false  auto_start_machines = true  min_machines_running = 1  processes = ["app"] [[vm]]  size = "shared-cpu-2x"  memory = "2048mb" [mounts]  source = "openclaw_data"  destination = "/data"

# obligatoire : jeton d’authentification du Gateway pour une liaison hors boucle localefly secrets set OPENCLAW_GATEWAY_TOKEN=$(openssl rand -hex 32) # clés API des fournisseurs de modèlesfly secrets set ANTHROPIC_API_KEY=example-anthropic-key-not-real # facultatif : autres fournisseursfly secrets set OPENAI_API_KEY=example-openai-key-not-realfly secrets set GOOGLE_API_KEY=... # jetons des canauxfly secrets set DISCORD_BOT_TOKEN=example-discord-bot-token

fly deploy

fly statusfly logs

fly ssh console

mkdir -p /datacat > /data/openclaw.json << 'EOF'{  "agents": {    "defaults": {      "model": {        "primary": "anthropic/claude-opus-4-6",        "fallbacks": ["anthropic/claude-sonnet-4-6", "openai/gpt-5.4"]      },      "maxConcurrent": 4    },    "list": [      {        "id": "main",        "default": true      }    ]  },  "auth": {    "profiles": {      "anthropic:default": { "mode": "token", "provider": "anthropic" },      "openai:default": { "mode": "token", "provider": "openai" }    }  },  "bindings": [    {      "agentId": "main",      "match": { "channel": "discord" }    }  ],  "channels": {    "discord": {      "enabled": true,      "groupPolicy": "allowlist",      "guilds": {        "YOUR_GUILD_ID": {          "channels": { "general": { "allow": true } },          "requireMention": false        }      }    }  },  "gateway": {    "mode": "local",    "bind": "auto",    "controlUi": {      "allowedOrigins": [        "https://my-openclaw.fly.dev",        "http://localhost:3000",        "http://127.0.0.1:3000"      ]    }  },  "meta": {}}EOF

exitfly machine restart <machine-id>

fly open

fly logs              # journaux en directfly logs --no-tail    # journaux récents

fly ssh console

Résolution des problèmes

« L’application n’écoute pas à l’adresse attendue »

Le Gateway se lie à 127.0.0.1 au lieu de 0.0.0.0.

Solution : ajoutez --bind lan à la commande du processus dans fly.toml.

Échec des vérifications d’état/refus de connexion

Fly ne peut pas atteindre le Gateway sur le port configuré.

Solution : vérifiez que internal_port correspond au port du Gateway (--port 3000 ou OPENCLAW_GATEWAY_PORT=3000).

Problèmes de mémoire insuffisante/OOM

Le conteneur redémarre continuellement ou est arrêté de force. Signes : SIGABRT, v8::internal::Runtime_AllocateInYoungGeneration ou redémarrages silencieux.

Solution : augmentez la mémoire dans fly.toml :

[[vm]]  memory = "2048mb"

Ou mettez à jour une machine existante :

fly machine update <machine-id> --vm-memory 2048 -y

512 Mo sont insuffisants. 1 Go peut fonctionner, mais risque d’entraîner une saturation de la mémoire en cas de charge élevée ou de journalisation détaillée. 2 Go sont recommandés.

Problèmes de verrouillage du Gateway

Le Gateway refuse de démarrer avec des erreurs indiquant qu’il est « déjà en cours d’exécution » après le redémarrage d’un conteneur.

Les fichiers de verrouillage d’exécution se trouvent dans <tmpdir>/openclaw-<uid>/gateway.<hash>.lock et gateway.state.<hash>.lock (sous Linux : /tmp/openclaw-<uid>/gateway.*.lock), et non sur le volume persistant /data. Ainsi, un redémarrage complet du conteneur les supprime normalement avec le reste du système de fichiers du conteneur. Si un verrou persiste (par exemple, un fly machine restart qui conserve le système de fichiers du conteneur) et bloque le démarrage, supprimez-le manuellement :

fly ssh console --command "rm -f /tmp/openclaw-*/gateway.*.lock"fly machine restart <machine-id>

La configuration n’est pas lue

--allow-unconfigured contourne uniquement le contrôle au démarrage. Il ne crée ni ne répare /data/openclaw.json. Vérifiez donc que votre configuration réelle existe et comprend "gateway": { "mode": "local" } pour un démarrage local normal du Gateway.

Vérifiez que la configuration existe :

fly ssh console --command "cat /data/openclaw.json"

Écriture de la configuration via SSH

fly ssh console -C ne prend pas en charge la redirection du shell. Pour écrire un fichier de configuration :

# echo + tee (canalisation de la machine locale vers la machine distante)echo '{"your":"config"}' | fly ssh console -C "tee /data/openclaw.json" # ou sftpfly sftp shell> put /local/path/config.json /data/openclaw.json

fly sftp peut échouer si le fichier existe déjà ; supprimez-le d’abord :

fly ssh console --command "rm /data/openclaw.json"

L’état n’est pas conservé

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 est écrit dans le système de fichiers du conteneur plutôt que sur le volume.

Solution : vérifiez que OPENCLAW_STATE_DIR=/data est défini dans fly.toml, puis redéployez.

Mise à jour

git pullfly deployfly statusfly logs

git pull + fly deploy constitue ici le processus supervisé : il reconstruit l’image à partir du fichier Dockerfile, de sorte que la version de la CLI/du Gateway, l’image du système d’exploitation de base et toutes les modifications apportées au fichier Dockerfile sont mis à jour ensemble. openclaw update dans le conteneur en cours d’exécution n’est pas la même opération, car l’image est livrée sous la forme d’une arborescence dist/ construite avec Docker, sans extraction .git ni installation globale gérée par npm qu’elle pourrait détecter ; consultez Mise à jour pour ce processus sur les installations de type machine virtuelle.

Mise à jour de la commande de la machine

Pour modifier la commande de démarrage sans redéploiement complet :

fly machines listfly machine update <machine-id> --command "node dist/index.js gateway --port 3000 --bind lan" -y # ou avec une augmentation de la mémoirefly machine update <machine-id> --vm-memory 2048 --command "node dist/index.js gateway --port 3000 --bind lan" -y

Une exécution ultérieure de fly deploy rétablit la commande de la machine à la valeur définie dans fly.toml ; appliquez de nouveau les modifications manuelles après le redéploiement.

Déploiement privé (renforcé)

Par défaut, Fly attribue des adresses IP publiques ; votre Gateway est donc accessible à l’adresse https://your-app.fly.dev et détectable par les scanners Internet (Shodan, Censys, etc.).

Utilisez deploy/fly.private.toml pour un déploiement renforcé sans adresse IP publique : il omet [http_service], de sorte qu’aucun accès entrant public n’est attribué.

Quand utiliser un déploiement privé

• Uniquement des appels/messages sortants (aucun Webhook entrant)
• Les tunnels ngrok ou Tailscale gèrent tous les rappels de Webhook
• L’accès au Gateway s’effectue par SSH, proxy ou WireGuard plutôt que depuis un navigateur
• Le déploiement doit être masqué aux scanners Internet

Configuration

fly deploy -c deploy/fly.private.toml

Ou convertissez un déploiement existant :

# répertorier les adresses IP actuellesfly ips list -a my-openclaw # libérer les adresses IP publiquesfly ips release <public-ipv4> -a my-openclawfly ips release <public-ipv6> -a my-openclaw # passer à la configuration privée afin que les futurs déploiements ne réallouent pas d'adresses IP publiquesfly deploy -c deploy/fly.private.toml # allouer une adresse IPv6 privée uniquementfly ips allocate-v6 --private -a my-openclaw

Après cela, fly ips list ne devrait afficher qu'une adresse IP de type private :

VERSION  IP                   TYPE             RÉGIONv6       fdaa:x:x:x:x::x      privée           globale

Accès à un déploiement privé

Option 1 : proxy local (le plus simple)

fly proxy 3000:3000 -a my-openclaw# ouvrir http://localhost:3000 dans un navigateur

Option 2 : VPN WireGuard

fly wireguard create# importer dans un client WireGuard, puis accéder au service via l'adresse IPv6 interne# exemple : http://[fdaa:x:x:x:x::x]:3000

Option 3 : SSH uniquement

fly ssh console -a my-openclaw

Webhooks avec un déploiement privé

Pour les rappels de Webhook (Twilio, Telnyx, etc.) sans exposition publique :

1. Tunnel ngrok : exécutez ngrok dans le conteneur ou comme conteneur compagnon
2. Tailscale Funnel : exposez des chemins spécifiques via Tailscale
3. Trafic sortant uniquement : certains fournisseurs (Twilio) permettent les appels sortants sans Webhooks

Exemple de configuration des appels vocaux avec ngrok, sous plugins.entries.voice-call.config :

{  plugins: {    entries: {      "voice-call": {        enabled: true,        config: {          provider: "twilio",          tunnel: { provider: "ngrok" },          webhookSecurity: {            allowedHosts: ["example.ngrok.app"],          },        },      },    },  },}

Le tunnel ngrok s'exécute dans le conteneur et fournit une URL publique de Webhook sans exposer l'application Fly elle-même. Définissez webhookSecurity.allowedHosts sur le nom d'hôte du tunnel afin que les en-têtes d'hôte transférés soient acceptés.

Compromis en matière de sécurité

Remarques

• Fly.io utilise l'architecture x86 ; le Dockerfile est compatible avec x86 et ARM.
• Pour l'intégration de WhatsApp/Telegram, utilisez fly ssh console.
• Les données persistantes résident sur le volume à l'emplacement /data.
• Signal nécessite signal-cli (une CLI basée sur Java) dans l'image ; utilisez une image personnalisée et conservez au moins 2GB de mémoire.

Coût

Avec la configuration recommandée (shared-cpu-2x, 2GB de RAM), prévoyez environ $10-15/mois selon l'utilisation ; l'offre gratuite couvre une partie de l'allocation de base. Consultez les tarifs de Fly.io pour connaître les tarifs actuels.

Étapes suivantes

• Configurez les canaux de messagerie : Canaux
• Configurez le Gateway : Configuration du Gateway
• Maintenez OpenClaw à jour : Mise à jour

Pages connexes

• Présentation de l'installation
• Hetzner
• Docker
• Hébergement sur VPS