Pourquoi OpenClaw a une exigence stricte de « ne jamais dormir »
Le cœur d'OpenClaw est un processus Node.js à long terme — Gateway. Il gère simultanément les Channel Adapters (réception de messages de Telegram, WhatsApp, Discord, etc.), le contexte Session, l'Agent Runtime et le planificateur heartbeat. Dès que le processus Gateway se termine, toutes les tâches Agent en cours sont interrompues et les tâches heartbeat ne se déclenchent plus.
Lors de l'exécution sur un Mac local, les cinq types d'événements suivants peuvent directement interrompre Gateway :
Mise en veille à la fermeture du couvercle :macOS entre en veille par défaut à la fermeture du couvercle, suspendant le processus Node.js. À la réouverture, les tâches heartbeat se sont accumulées et un redémarrage est nécessaire pour rétablir la planification normale.
Redémarrage après mise à jour système :macOS demande un redémarrage après une mise à jour automatique nocturne. Sans personne pour surveiller, Gateway reste hors ligne jusqu'au prochain démarrage.
Fenêtres contextuelles Keychain et d'autorisation :macOS peut afficher des fenêtres d'autorisation lors de l'exécution de commandes shell. Sans surveillance, ces fenêtres suspendent tout le flux d'interaction.
Contamination du contexte multi-utilisateurs :Sur un Mac partagé, les chemins, variables d'environnement et clés API de différents utilisateurs peuvent se chevaucher, entraînant des échecs d'exécution de compétences.
Pas de garantie SLA :La machine de développement gère aussi le débogage local, avec une contention CPU/mémoire imprévisible. Pour intégrer cela dans les standards de livraison d'équipe, un Mac local ne peut pas servir de base contractuelle.
Ces cinq points pointent vers la même cause fondamentale :le Mac local est conçu pour une utilisation interactive, pas pour des processus en résidence sans surveillance.
Mac local vs nœud cloud KVMNODE : comparaison de stabilité
Migrer OpenClaw vers un nœud cloud ne signifie pas perdre le contrôle local — les données, configurations et scripts de compétences restent dans votre dépôt. Le nœud cloud se charge uniquement de fournir un environnement d'exécution qui ne dort jamais.
| Dimension | Mac local | Nœud cloud KVMNODE |
|---|---|---|
| Disponibilité des processus | Affecté par la veille, les mises à jour, les coupures | En ligne 7×24, redémarrage automatique pm2 |
| Interruptions par fenêtres contextuelles | Fenêtres contextuelles Keychain nécessitent une confirmation manuelle | Autorisations fixées après la première configuration, pas de fenêtres GUI |
| Isolation multi-utilisateurs | Risque de contamination des chemins et des clés | Nœud indépendant, environnement mono-utilisateur, audit clair |
| Stabilité des performances | Contention de ressources avec les tâches locales | CPU/mémoire dédiés, sans risque de préemption |
| Flexibilité géographique | Position physique fixe | Nœuds multi-régions disponibles en Asie, Europe, Amérique |
| Structure des coûts | CapEx + électricité + maintenance | Facturation flexible par jour/mois, sans coûts de mise hors service |
Migrer OpenClaw vers un nœud cloud, c'est éliminer définitivement de votre checklist quotidienne la question « Est-ce que Gateway tourne aujourd'hui ? ».
Dans la console KVMNODE, choisissez la région selon votre cluster d'utilisateurs principal. Cela convergera l'entrée et l'exécution dans la même zone géographique, avec une base RTT claire pour les SLO futurs.
Cas d'utilisation × Mode de déploiement : quand migrer vers le cloud
Tous les utilisateurs n'ont pas besoin de migrer immédiatement — si vous n'exécutez que des scripts occasionnels, un Mac local suffit amplement. La matrice ci-dessous vous aide à décider selon l'intensité d'utilisation :
| Cas d'utilisation | Mode recommandé | Critères de décision de migration |
|---|---|---|
| PoC personnel / Expérimentation du week-end | Mac local | Interruption acceptable, pas d'exigence SLA |
| Production personnelle (journal du matin/surveillance/réponse auto) | Nœud cloud · Mensuel | heartbeat doit se déclencher 7×24 |
| Petite équipe partageant un Agent (2–10 personnes) | Nœud cloud · Mensuel | Risque élevé de contamination des chemins partagés |
| Automatisation d'entreprise / Disponibilité garantie externe | Nœud cloud · Long terme | SLA doit être contractualisé, audit de conformité obligatoire |
| Équipe multi-fuseaux horaires | Multi-nœuds · Même zone que le lien principal | La latence de l'Agent impacte directement l'expérience utilisateur |
fréquence_heartbeat = nombre de déclenchements par heure (> 4 fois/jour recommande la migration) tolérance_interruption = faible | moyenne | élevée (faible = migration obligatoire) taille_équipe = 1 | 2-10 | 10+ (nœud dédié recommandé pour plus de 2 personnes) Conclusion = l'un des critères ci-dessus déclenché → prioriser le nœud cloud KVMNODE
Préparation avant migration :Si vous exécutez déjà plus de 100 AgentSkills ou avez connecté plusieurs Channel Adapters, notez d'abord les chemins absolus du répertoire de compétences actuel et la configuration .env avant migration, à réutiliser directement sur le nouveau nœud.
Six étapes pour déployer OpenClaw Gateway sur un nœud KVMNODE
L'ordre ci-dessous peut être directement remis aux ops pour exécution. Si votre équipe dispose déjà d'Ansible ou Terraform, les étapes 2, 4, 5 peuvent être remplacées par des tâches idempotentes, mais la réception reste basée sur « pm2 persistance effective + journaux de boucle heartbeat ».
Choisir la région du nœud et établir la connexion SSH :Dans la console KVMNODE, choisissez le nœud le plus proche de vos utilisateurs principaux ou de la source des webhooks. Configurez le ~/.ssh/config local pour une connexion sans mot de passe en un clic.
Confirmer l'environnement d'exécution :Après connexion, exécutez node -v(nécessite ≥ 18.x) et npm -v. Confirmez que le nœud peut accéder aux points de terminaison LLM API (OpenAI / Anthropic / Google).
Cloner le dépôt et installer les dépendances :Exécutez git clone https://github.com/OpenClawHQ/openclaw.git && cd openclaw && npm ci à vos données disque et à votre trafic réseau.
Migrer les fichiers de configuration (.env et YAML) :Transférez via scp le fichier .env(clés LLM API, ports d'écoute) et config/*.yaml. Il est strictement interdit de les écrire en clair dans le dépôt de code.
Configurer le gardien de processus (pm2) :Exécutez npm install -g pm2 && pm2 start npm --name "openclaw-gw" -- start && pm2 save && pm2 startup à vos données disque et à votre trafic réseau.
Écrire les critères de réception et vérifier heartbeat :Déclenchez manuellement une tâche heartbeat, confirmez que les journaux montrent le cycle complet « exécution→observation→écriture mémoire », et notez les paramètres clés dans le Runbook.
Trois paramètres de configuration obligatoires en production
Stratégie de redémarrage du gardien de processus :Configurez max_restarts: 10 et min_uptime: 5000. Arrêtez après la limite et envoyez une alerte via pm2 webhook pour éviter que les boucles de crash masquent les vrais problèmes.
Isolation des ports et contrôle d'accès :Le Dashboard écoute par défaut sur le port 3000, ne doit pas être exposé sur Internet. Accédez via tunnel SSH (ssh -L 3000:localhost:3000 your-node). Bloquez les connexions entrantes sur le port 3000 au pare-feu.
Permissions de chemin AgentSkills :Placez les compétences tierces dans un répertoire indépendant, exécutez avec un utilisateur à faibles privilèges. Autorisez précisément la plage de répertoires accessibles au processus OpenClaw.
Avertissement de sécurité :OpenClaw dispose d'un accès système (système de fichiers + commandes shell). Ne jamais exécuter Gateway avec l'utilisateur root sur les nœuds de production. Ne pas installer de AgentSkills tiers provenant de sources inconnues.
Comparé aux ajustements répétés de stratégie de veille sur un Mac local, un nœud cloud dédié KVMNODE élimine définitivement de votre checklist quotidienne la question « Est-ce que Gateway tourne aujourd'hui ? ».KVMNODE VPS haute performance est un point de départ plus stable : ressources dédiées, en ligne 7×24, facturation flexible par jour/mois.