2026 : OpenClaw 7×24 — LanceDB hébergé cloud, mémoire durable sur Mac Mini loué : sync passerelle, reconnexion et fenêtres de nettoyage

Public : plateforme et intégrateurs qui exposent une passerelle OpenClaw sur Mac Mini loué et externalisent le stockage vectoriel tout en gardant l’état conversationnel local.

Livrable : prérequis, stratégie de synchronisation du backend mémoire, retries et reconnexion, quotas disque, liste de contrôle et FAQ. Pour le cadre 7×24 : auto-rétablissement, heartbeat et dépannage, rotation et alertes disque. Achat sans compte pour dimensionner RAM/NVMe.

Prérequis de déploiement

Gelez dans l’en-tête du runbook les versions OpenClaw, client LanceDB et Python. Limitez l’IAM à un préfixe de bucket unique avec ListBucket et PutObject sur ce préfixe seulement. Placez la mémoire durable sur un volume APFS rapide, hors volume système, et réservez au moins 50 Go libres pour le staging Lance avant la montée en charge. Prenez une photo hebdomadaire du répertoire de checkpoints pour les audits et restaurations ponctuelles.

• Horloge. NTP fiable : les séquences de checkpoint et les ETag objet doivent rester cohérents entre hôtes.
• Écriture unique. Un seul agent launchd avance le journal ; bloquez les doublons de plist qui relanceraient un second writer.
• Secrets. Fichiers chmod 600 ou trousseau ; rotation avant expiration silencieuse des jetons cloud.

Stratégie de synchronisation

Découplez le backend mémoire : la passerelle sur le Mac loué conserve la mémoire durable chaude (journaux de session, traces d’outils, faits récents) et le scratch d’embedding ; le LanceDB dans le cloud porte l’index canonique (tableaux de vecteurs, index IVF ou scalaires, manifestes). Après chaque lot upsert, avancez un checkpoint local, exécutez un flush Lance, puis publiez les fragments : une panne partielle rejoue sans dupliquer les vecteurs ni lire des fichiers « à moitié écrits ».

Sondes de santé en couches : vivacité du processus launchd, HTTP readiness de la passerelle, lecture head légère sur Lance (latence), enfin un contrôle IAM sur un objet sentinelle. Si Lance échoue alors que HTTP répond 200, orientez l’astreinte vers le stockage et non vers une réinstallation aveugle d’OpenClaw.

Échecs et nouvelles tentatives

Lors des déconnexions réseau ou des 5xx stockage, appliquez un backoff exponentiel plafonné à cinq minutes avec jitter ~30 % pour éviter l’effet troupeau. Ouvrez un disjoncteur après des 500 répétés et repassez en mémoire lecture seule jusqu’à ce que toutes les sondes redeviennent vertes. Ne supprimez un checkpoint local qu’après concordance de l’ETag cloud.

Déclenchez un webhook ou une alerte après trois échecs de sonde en dix minutes. Sur launchd, gardez un ThrottleInterval raisonnable pour qu’une boucle de mauvais identifiants ne remplisse pas le disque de journaux.

Nettoyage des quotas disque

Exécutez compaction Lance et l’élagage des journaux uniquement dans des fenêtres calmes (nuit UTC ou créneau locataire documenté). En dehors de ces plages, gardez des seuils jaune (espace libre faible, par ex. ~20 % ou <80 Go) et rouge (pause d’écriture) pour protéger l’APFS. Après vacuum vers le cloud, rognez ~/Library/Logs si nécessaire, puis retirez les archives mémoire hors rétention une fois l’archive froide vérifiée.

• Règle double clé : exiger à la fois pourcentage d’espace libre et marge d’inodes avant de rouvrir les écritures lourdes.
• Manifeste d’abord : ne supprimez le staging local qu’après lecture du manifeste cloud listant les nouveaux fragments.

Liste de contrôle (étapes reproductibles)

1. Consigner versions, régions et ARN IAM dans l’en-tête du runbook.
2. Créer l’URI LanceDB cloud et valider une requête head en lecture seule depuis le Mini.
3. Pointer la mémoire durable OpenClaw vers un dossier APFS dédié avec sémantique d’écriture unique.
4. Mettre en place la sync incrémentale checkpointée après chaque lot d’embeddings.
5. Déployer les sondes superposées : processus, HTTP, Lance, IAM.
6. Activer backoff exponentiel plafonné + disjoncteur + mode lecture seule.
7. Planifier compaction et rotation des logs dans les fenêtres calmes uniquement.
8. Chaos drill : couper le VPN ~90 s ; vérifier absence de doublons et reprise propre.

Repères. Sonde HTTP toutes les 60 s ; contrôle Lance « profond » toutes les 5 min ; plafond backoff 5 min ; page humaine après 3 échecs / 10 min.

FAQ

LanceDB doit-il vivre uniquement sur le Mac loué ?

Non comme source unique : gardez le chaud local, mais le canon dans le cloud pour survivre au remplacement d’hôte et accélérer le MTTR.

En quoi la mémoire durable diffère du tableau vectoriel ?

La première porte l’état de session ; LanceDB porte la récupération sémantique. Checkpointez les deux pour ne jamais lire des vecteurs à moitié écrits.

Pourquoi ne pas se fier à un seul curl ?

Le HTTP peut rester vert pendant une expiration IAM ou un writer bloqué ; les couches séparent applicatif, index et identité.

Quelle politique pour un gateway 7×24 ?

Plafond de backoff, jitter, disjoncteur sur 5xx répétés, et file d’attente côté opérateur plutôt que boucle serrée sur le stockage.