OpenClaw exige un processus stable, un état durable pour les sessions et les jetons, et une URL HTTPS unique que les fournisseurs de messagerie puissent joindre pour les webhooks. En 2026, deux empreintes dominent : une machine Fly.io avec volume attaché et TLS géré, ou un VPS Linux générique avec systemd, reverse proxy et répertoire de données monté. Ce billet les compare sur ce qui casse vraiment la prod : où vit l’état, comment l’URL publique se comporte au déploiement, comment Slack ou Telegram rejouent les callbacks, et comment câbler les health checks pour qu’un redémarrage n’efface pas des canaux déjà appairés. Pour les scénarios multi-canal côté bots, voir aussi OpenClaw 2026, double canal Telegram et Discord : bots, appairage, matrice de permissions et FAQ conflits multi-canaux.
Matrice de décision (vue rapide)
Choisissez Fly lorsque la plateforme doit porter les déploiements rolling, l’anycast et le renouvellement des certificats avec peu d’Ansible. Choisissez un VPS lorsqu’il vous faut des IP de sortie fixes, des modules noyau arbitraires, plusieurs agents sur le même hôte, ou une frontière conformité que vous maîtrisez de bout en bout. Les patrons « surface d’attaque minimale » (gateway en loopback, SSH ou HTTPS scindé) se traduisent surtout par une grille pare-feu et des règles d’ingress explicites sur le VPS. Si une partie de l’équipe reste sur poste Windows, les pièges de chemins, WSL2 vs hôte et le doctor gateway sont détaillés dans 2026 — OpenClaw sur Windows : installation reproductible PowerShell, WSL2 vs hôte, Gateway résidente et FAQ PATH / doctor par paliers — la même exigence de chemins canoniques s’applique, quel que soit l’OS.
| Axe | Fly.io (machines) | VPS Linux (systemd + proxy) |
|---|---|---|
| État persistant | Attacher un volume et le monter là où OpenClaw attend config et magasin de session ; sans volume, les redémarrages sont éphémères. | Répertoire dédié sur disque (souvent sous /var/lib ou volume Docker) ; les instantanés portent votre histoire de migration. |
| Entrée HTTPS publique | Le proxy Fly termine le TLS ; aligner les ports d’écoute internes avec les services fly.toml. |
Caddy ou Nginx sur l’hôte ; vous gérez DNS, ACME et OCSP vous-même. |
| Webhooks (callbacks) | Nom d’hôte stable par app ; attention à l’ordre de déploiement pour que le processus écoute avant que Slack ne marque l’URL comme malsaine. | Même discipline d’URL ; plus simple pour ajouter WAF ou listes IP en bordure si l’éditeur publie des plages. |
| Health checks | Checks HTTP sur un chemin léger /healthz ; échec → remplacement de la machine. |
Restart=on-failure sous systemd + moniteur externe optionnel ; éviter les sondes qui exigent l’auth canal. |
Persistance : volumes vs bind mounts
Sur Fly, déclarez un volume dans la même région que la machine et montez-le sur le chemin utilisé par votre point d’entrée conteneur pour identifiants, métadonnées de canaux et caches locaux. Monter plusieurs machines sans stockage partagé duplique l’état ; pour OpenClaw, viser une instance « writer » unique tant que le projet ne documente pas explicitement le multi-nœud. Sur VPS, préférez un bind mount unique, propriété d’un utilisateur de service non root, avec des sauvegardes filesystem cohérentes avec les magasins type SQLite.
Ingress, webhooks et pression de replay
Les éditeurs livrent des événements avec retries et budgets de latence serrés. La gateway doit répondre vite, vérifier les signatures en bordure quand c’est possible, et mettre le travail lourd en file plutôt qu’en ligne dans le handler. Sous Fly, vérifiez que les timeouts HTTP internes restent inférieurs au timeout client du fournisseur pour éviter des livraisons en double perçues comme des bugs de replay. Sous Nginx ou Caddy, journalisez séparément le statut amont des erreurs de poignée TLS : un renouvellement ACME ne doit pas être lu comme un 500 applicatif.
Health checks qui survivent aux rollouts
Exposez un GET peu coûteux qui valide la config et l’écriture disque sur le volume, pas des appels live aux API tiers à chaque sonde. Complétez par une sonde « capacité à mettre en file » dans votre stack d’observabilité. Sur Fly, calibrez l’intervalle pour éviter de remplacer des machines saines lors de vols CPU voisins. Sous systemd, n’utilisez Type=notify que si le binaire supporte sd_notify ; sinon privilégiez codes de sortie et limites de backoff plutôt qu’une tempête de redémarrages.
Les journaux fichier sous le répertoire d’état méritent la même discipline : si vous ne scrapez que la sortie standard du conteneur, prévoyez rotation ou forwarding, sinon un disque plein peut rester « vert » au health check jusqu’au blocage en écriture. En dual-stack, vérifiez si la sonde part en IPv4 ou IPv6 par défaut pour ne pas être vert en loopback alors que l’enregistrement AAAA public pointe vers un listener mort.
1. curl -v https://votre-hôte/healthz # TLS + routage 2. ls -la $OPENCLAW_STATE_DIR # volume monté ? 3. journalctl -u openclaw -b # ou fly logs --app … 4. comparer secret webhook / UI éditeur # boucles 401/403 silencieuses
FAQ : pannes reproductibles
Q : Slack marque l’URL Events comme invalide après chaque déploiement. Démarrez l’écouteur avant de basculer le trafic ; gardez le chemin identique entre préprod et prod ; alignez le secret de signature entre l’UI du fournisseur et l’environnement d’exécution.
Q : les sessions ont disparu du jour au lendemain. Presque toujours volume non monté ou conteneur ayant écrit dans la couche d’image. Vérifiez le montage dans la tâche en cours, pas seulement dans le Dockerfile.
Q : health check vert mais timeouts côté utilisateurs. La sonde tape probablement localhost alors que les webhooks saturent le front TLS. Ajoutez une sonde externe ou un moniteur tiers.
Q : Fly affiche plusieurs machines après un scale. Sans élection de leader ni stockage partagé, évitez l’horizontal : les webhooks dupliqués feront la course sur les mêmes automatisations aval.
À côté d’OpenClaw, un socle macOS sérieux
Les gateways Linux et les machines Fly excellent pour exposer OpenClaw au monde, mais beaucoup d’équipes ont encore besoin d’un ancrage macOS silencieux pour Xcode, la signature et les outils natifs. Un Mac mini M4 dans le cloud combine ergonomie Unix, consommation idle d’environ 4W, et le durcissement Gatekeeper / SIP — tout en gardant assez de bande passante mémoire unifiée pour que vos agents locaux restent réactifs pendant que le bord Linux absorbe les webhooks.
Face à une tour Windows recyclée, Apple Silicon tient mieux la charge de scripts longs, macOS plante rarement sur des jobs sans écran, et les mêmes clés SSH et workflows Homebrew que sur votre VPS évitent de jongler entre deux mondes d’exploitation.
Si vous voulez une capacité macOS au même niveau de sérieux que la passerelle que vous venez de cadrer, le Mac mini M4 cloud VPSSpark est un palier naturel — découvrir les offres et garder bots, builds et signature sur du matériel pensé pour tourner toute la journée.