OpenClaw sur Cloudflare Containers

La page Cloudflare de la documentation est la plus inhabituelle des pages d’hébergement : une installation OpenClaw derrière un Worker Cloudflare et un Durable Object nommé, qui fait tourner l’image officielle dans un conteneur Cloudflare, avec Litestream qui diffuse les bases SQLite vers un compartiment R2. Elle est marquée expérimentale, et l’avertissement est précis : Litestream protège les bases SQLite, pas le répertoire d’état complet d’OpenClaw. Voici comment les pièces s’assemblent, la séquence de déploiement, la vérification sur laquelle la documentation insiste, le modèle de coût, et les limites.

Comment cela s’assemble

• Le Worker transmet chaque requête HTTP et WebSocket à un seul nom de Durable Object stable ; cet objet possède une seule instance de conteneur et constitue la barrière à écrivain unique autour de la réplique Litestream.
• Le conteneur expose la passerelle sur le port 8080 et le Durable Object interroge le point d’accès de santé avant d’y router ; le gabarit déploie un conteneur standard-2 avec une seule instance.
• Litestream surveille les racines SQLite d’état et d’agents et diffuse leurs journaux d’écriture anticipée vers R2 ; au démarrage, le point d’entrée liste le compartiment comme manifeste de restauration, rejette les chemins hors de ces racines, restaure chaque base, et seulement ensuite lance la passerelle.
• Mesuré sur le gabarit : environ 2,4 secondes de l’écriture à la réplique, environ 9 secondes pour restaurer les deux bases, et une passerelle saine à peu près 13 secondes après le démarrage, tous des ordres de grandeur plutôt que des garanties.

Répétez la récupération avant d’en avoir besoin. Un chemin de restauration non testé n’est pas une sauvegarde.

Le déployer

La séquence : cloner le gabarit, se connecter avec Wrangler et confirmer le compte, créer le compartiment R2 et un jeton d’API R2 limité à celui-ci, construire une image dérivée à partir d’une empreinte immuable de l’image officielle pour linux/amd64 et la pousser vers un dépôt Docker Hub public, puisque Cloudflare tire les images publiques de Docker Hub et que GHCR n’est pas pris en charge, puis déployer le Worker. Les secrets entrent par Wrangler : les deux clés Litestream, le jeton de passerelle, puis les variables de fournisseurs et de canaux, dont chacune doit aussi figurer dans la liste d’autorisation explicite d’environnement du conteneur. Le premier démarrage exige une session interactive : activer temporairement SSH dans la configuration, redéployer, se connecter par Wrangler, lancer l’assistant de démarrage non interactif avec des références de secrets et l’authentification par jeton, ajouter un canal depuis l’environnement, lancer le docteur, et garder cette recette dans un runbook privé, parce qu’un disque de conteneur neuf ne conserve pas la configuration générée.

Vérifier, puis la facture

• Le point d’accès de santé dit que l’écouteur est levé, celui de disponibilité exige le jeton porteur, et celui de démarrage rapporte un démarrage terminé en ignorant l’état des canaux ; il existe sur les images à partir de la v2026.8.1.
• La réplication se prouve en listant le préfixe des répliques du compartiment avec un client compatible S3, puisque Wrangler ne peut pas lister les clés ; un préfixe vide après des minutes d’activité veut dire qu’elle ne fonctionne pas. Puis répétez la récupération : envoyez un message, attendez une dizaine de secondes, supprimez l’instance, rouvrez l’URL du Worker, et confirmez que la conversation est toujours là.
• Les conteneurs exigent l’offre Workers payante et facturent la mémoire et le disque sur les ressources provisionnées tant qu’ils sont éveillés : l’instance par défaut provisionne 1 vCPU, 6 Gio de mémoire et 12 Go de disque, et un mois en marche continue revient à environ 40 à 50 dollars américains, surtout de la mémoire. Les canaux à socket comme Discord, Slack en mode Socket et WhatsApp gardent le conteneur éveillé ; les installations à webhooks seuls peuvent dormir et ne rien facturer, le seul cas où cette cible est vraiment bon marché.

Sauvegarde et restauration d’OpenClaw couvre les archives complètes vers lesquelles la documentation renvoie pour tout ce que Litestream ne protège pas, et Les secrets dans OpenClaw la configuration par références qu’utilise l’amorçage.

Les limites

Écrivain unique, donc ne jamais augmenter le nombre d’instances ni contourner le Durable Object. Un point de récupération à l’échelle des secondes, puisque l’intervalle de synchronisation d’une seconde n’est pas une réplication synchrone. Un disque éphémère, donc la configuration, les fichiers d’identifiants, les extensions et les espaces de travail ne reviennent que d’une archive complète, et la mise à zéro, activée seulement quand chaque canal passe par webhook, repart d’un disque neuf après dix minutes d’inactivité. La restauration est un voyage dans le temps : rétablir des octets plus anciens peut désynchroniser les identifiants de canaux à cliquet, WhatsApp en particulier, et ramène en arrière les approbations et l’état de livraison. Les messages WebSocket sont plafonnés à 32 Mio, il n’y a pas d’adresse de sortie fixe, et c’est un gabarit de déploiement, pas un fournisseur de workers cloud. OpenClaw sur Fly.io et OpenClaw sur Docker sont les voies classiques quand ces limites comptent.

Sur Diali

Diali garde le répertoire d’état sur un volume persistant, et l’option Sauvegardes (incluse avec Max) prend des instantanés quotidiens avec restauration en un clic, si bien que la question de la récupération limitée à SQLite ne se pose jamais. OpenClaw hébergé sur Diali est l’assistant et Ce que coûte OpenClaw place nos offres à côté d’un conteneur en marche continue.

• Un Worker, un Durable Object, un conteneur, un écrivain.
• Litestream restaure SQLite et rien d’autre.
• Les sockets le gardent éveillé ; les webhooks le laissent dormir.