OpenClaw Home Server : infrastructure auto-reparante via SSH et Kubernetes

Avoir un serveur a la maison, c'est etre d'astreinte pour sa propre infra. Services down a 3h du matin, certificats qui expirent en silence, disque qui se remplit, pods Kubernetes en crash-loop pendant que vous etes en week-end. Vous vouliez du controle, mais vous avez surtout gagne un nouveau job.

Le pattern "self-healing home server" consiste a donner a OpenClaw un acces SSH, des cron jobs, et une connaissance structuree de votre infra. L'agent detecte, diagnostique et corrige des problemes courants avant meme que vous ne receviez une alerte.

Ce guide explique comment mettre en place un agent infra qui tourne en continu, et surtout comment le faire de maniere securisee.

---

Le probleme : un home lab a besoin d'un sysadmin

Les problemes classiques :

• Monitoring sans reponse : Grafana/Prometheus detectent, mais quelqu'un doit intervenir.
• SSH depuis le telephone : lent, stressant, propice aux erreurs.
• Connaissance non documentee : la topologie et les dependances restent dans votre tete.
• Taches repetitives : rotation logs, backups, updates, certificats.
• Drift IaC : Terraform/Ansible/manifests K8s evoluent et cassent.

Un agent persistent peut jouer le role de sysadmin.

---

La solution : un agent infra persistent avec runbooks

OpenClaw peut :

• se connecter en SSH aux machines
• executer kubectl sur votre cluster
• lancer des checks sur un planning
• appliquer des fixes (restart pods, corriger config)
• envoyer un briefing quotidien
• tenir un journal d'actions

Mais il faut des regles strictes. Un agent DevOps sans garde-fous est dangereux.

---

Skills et prerequis

Vous aurez besoin de :

• SSH (cle dediee)
• kubectl si vous avez Kubernetes (K3s, etc.)
• un outil mail/calendrier optionnel (gog)
• une base de runbooks (markdown)

Pour les skills OpenClaw, voir : Guide des skills OpenClaw.

---

Setup pas a pas

Etape 1 : definir le scope dans AGENTS.md

## Infrastructure Agent

Tu es mon agent d'infrastructure.

Acces :
- SSH sur les machines du reseau (ex: 192.168.1.0/24)
- kubectl sur le cluster K3s
- lecture Gmail/Calendar via gog (optionnel)
- dossier runbooks: ~/infrastructure/runbooks/

Regles :
- jamais de secrets hardcodes
- jamais de push direct sur main
- log obligatoire dans ~/logs/infra-changes.md
- operations destructives: demander confirmation
- si doute: alerter plutot qu'agir

Etape 2 : configurer SSH (cle dediee)

ssh-keygen -t ed25519 -f ~/.ssh/openclaw_infra -N ""
ssh-copy-id -i ~/.ssh/openclaw_infra.pub admin@192.168.1.10

Ajoutez des alias dans ~/.ssh/config.

Etape 3 : planifier les cron jobs (le vrai produit)

Exemple de planning :

• toutes les 15 min : checks services, auto-recovery simple
• toutes les heures : CPU/RAM/disque, alerts, triage notifications
• toutes les 6h : openclaw gateway status, certificats, backup status
• chaque jour : briefing 8h
• chaque nuit : audit securite

Prompt :

Configure un systeme de checks :
- endpoints HTTP
- DNS
- utilisation disque
- statut pods Kubernetes

Si un service tombe :
1) diagnostiquer
2) tenter un fix safe (restart)
3) verifier
4) si echec apres 2 essais, alerter avec logs

Etape 4 : ecrire des runbooks (procedures)

Ne laissez pas l'agent improviser. Donnez-lui des checklists.

Exemples :

Pod CrashLoopBackOff

1. kubectl describe pod
2. kubectl logs --tail=50
3. si OOMKilled: augmenter limites
4. si config: verifier ConfigMap/Secret
5. kubectl rollout restart
6. log dans infra-changes

Disque plein (>90%)

1. identifier gros dossiers
2. nettoyer docker/journald
3. verifier logrotate
4. si pas resolu: alerte

Certificat expirant

1. verifier cert-manager
2. renouveler / recreer
3. verifier TLS

Etape 5 : briefing quotidien

Chaque jour a 8h, envoie un briefing :

- Meteo
- Calendriers
- Sante systeme (CPU/RAM/Disque)
- Services UP/DOWN
- Actions auto-healing des 24h
- Alertes et points d'attention

---

Aller plus loin : tunnel, secrets et scanning

Connecter ClawRapid a votre reseau maison

Si votre agent tourne sur un serveur distant, vous devez exposer SSH de maniere securisee. Deux options populaires :

• Tailscale : simple, stable, mesh VPN
• WireGuard : control total, un peu plus technique

Regle : ne pas exposer SSH sur Internet sans tunnel.

Secrets management

Ne mettez pas de mots de passe dans des fichiers. Utilisez :

• un vault dedie (ex: 1Password)
• des variables d'environnement
• des tokens scopes minimum

Secret scanning

Ajoutez du scanning automatique (ex: TruffleHog) pour eviter qu'un secret ne parte dans git.

Installe un hook pre-push qui bloque tout commit contenant des secrets verifies.

Principe d'escalade

• si l'agent ne comprend pas, il alerte
• si l'action est destructrice, il demande confirmation
• si 2 tentatives echouent, il stop et vous donne des diagnostics

C'est la difference entre un agent utile et un agent dangereux.

Securite : garde-fous indispensables

Le risque numero 1 : un agent peut exposer un secret ou faire une action irreversible.

Bonnes pratiques :

• cle SSH dediee, privileges limites
• segmentation reseau
• branch protection (PR obligatoire)
• secret scanning (TruffleHog en pre-push)
• logs complets (SSH, changes)
• approvals pour actions sensibles

Citation utile a garder en tete : un agent peut "hardcoder" un secret si vous ne le bloquez pas.

---

Exemple concret d'auto-healing

Scenario : a 3h15, un pod crash-loop car une variable d'environnement est mal ecrite.

Avec l'agent :

1. check detecte le crash
2. l'agent lit les logs
3. identifie une faute de frappe dans la ConfigMap
4. corrige, redeploie
5. verifie que le service remonte
6. log l'action et le resume dans le briefing du matin

Vous dormez.

---

Comment ClawRapid s'integre

Un agent infra doit tourner 24/7. ClawRapid fournit un hebergement OpenClaw stable avec planification et heartbeat. Connectez ensuite votre home lab via un tunnel securise (Tailscale, WireGuard, Cloudflare Tunnel) et donnez a l'agent un acces SSH limite.

---

FAQ

Est-ce safe de donner SSH a un agent IA ?

Oui si vous appliquez des garde-fous : privileges limites, approvals, logs, secret scanning, segmentation.

Que faire si l'agent aggrave un probleme ?

Regle d'escalade : 2 tentatives max, puis alerte. Et interdiction d'actions destructives sans confirmation.

Faut-il Kubernetes ?

Non. Le pattern marche aussi avec un NAS, Pi-hole, Docker Compose.

Quels outils de monitoring recommandes ?

Grafana/Prometheus pour metrics, Uptime Kuma pour endpoints, Loki pour logs. L'agent lit ces signaux et agit.

Peut-on l'utiliser en cloud (AWS/GCP) ?

Oui. Remplacez SSH/kubectl par aws, gcloud, etc. Pour isoler les credentials, combinez avec OpenClaw + n8n.

Comment commencer petit ?

Donnez SSH a une machine, ajoutez checks disque + DNS + endpoint, et un briefing quotidien. Etendez ensuite.

---

A lire ensuite

• 30+ Cas d'usage OpenClaw
• Guide des skills OpenClaw
• Integration n8n