ZeroClaw (im Chat meist Claw) ist ein kompakter KI-Agent für Cluster-Arbeit auf hydra: Flux-Status prüfen, fehlgeschlagene Pods erklären, Renovate dry-runen, Git-Patches entwerfen. Er teilt dasselbe GitOps-Monorepo mit dem Cluster — es gibt kein zweites Control Plane, keine parallele „Agent-Konfiguration“ außerhalb von Git.

Die Unterhaltung läuft über Matrix auf matrix.this-is-fine.social (Synapse im selben Fediverse-DNS wie snac). Web-Zugriffe gehen über MCP an einen Scrapling-Sidecar statt eingebauter Browser-Tools. Deployment: k8s/clusters/hydra/applications/zeroclaw/zeroclaw/; Workspace-Quellcode im Repo unter zeroclaw/workspaces/main/.

Claw ist ops-fokussiert: Cluster-Zustand lesen, Skills aus Git befolgen, Änderungen vorschlagen, die weiterhin menschliches Review und einen Merge erfordern. Er ersetzt weder On-Call noch Change Management — er verkürzt den Weg von Symptom zu dokumentiertem Patch.

Architektur und Konzepte

Ein GitOps-Agent im Lab bedeutet: Policy und Skills leben in Git, Credentials zur Laufzeit sind read-only. Statt eines monolithischen System-Prompts nutzt Claw kurze Agent Skills — Markdown-Playbooks unter skills/ für Flux-Debug, Storage-Checks, Renovate-Dry-Runs, Radicle-Patches.

Das Homelab ist kein Spielzeug-Cluster, sondern ein bewusst kleines Produktions-Vorbild: Layouts, Operatoren und Anwendungen werden hier erprobt, bevor sie in die „echte“ Umgebung wandern. Nach einem kurzen manuellen Bootstrap übernimmt Flux CD die Synchronisation mit Git — die klassische GitOps -Schleife aus deklariertem Zustand in der Versionskontrolle und Controllern, die Abweichungen automatisch ausgleichen.

Der produktive Cluster heißt hydra. Worker-Nodes laufen mit Talos Linux auf Turing Pi RK1-Boards (Talos 1.13.2 laut k8s/clusters/hydra/flux/vars/cluster-config.yaml). Images kommen aus der Talos Image Factory (metal-arm64, Profil sbc-rockchip / turingrk1). Talos hält das Node-OS schlank und ausschließlich API-gesteuert: kein SSH, kein Paket-Patching auf den Hosts. Die operative Komplexität liegt in Kubernetes-Manifesten — genau dort, wo GitOps hingehört.

Alles nach dem ersten Bootstrap lebt in einem Monorepo (rad:z6MQ7ck2rSh7h4qEgbRYg3ftnrGv, HTTPS-Clone über seed.this-is-fine.io). Wer die Struktur nachvollziehen will: unter k8s/clusters/ die gemeinsamen Layer in common/ sowie die hydra-Overlays. Die Talos Machine Config (talconfig) ist dort versioniert, wird aber mit talosctl angewendet — nicht mit Flux. Diese Grenze ist Absicht.

IRC ist tot, lang lebe IRC. Während der Rest der Welt durch Messenger-Silos zieht, hänge ich nach wie vor gern in ein paar IRC-Kanälen ab — und damit mir dabei keine Zeile entgeht, betreibe ich einen Bouncer. Bei mir ist das ZNC , läuft auf Kubernetes und erreicht seine Upstream-Netze nicht direkt, sondern als Onion-Services über Tor.

Soziale Netze müssen niemandem gehören. Genau das ist der Reiz des Fediverse: ein Verbund unabhängiger Server, die über ein gemeinsames Protokoll miteinander reden, statt sich einer zentralen Plattform unterzuordnen. Auf meinem Lab betreibe ich deshalb unter this-is-fine.social eine eigene Mastodon -Instanz. Dieser Beitrag erklärt, warum mir das wichtig ist — und wie der Stack auf Kubernetes konkret zusammengesetzt ist.

Jedes Lab braucht ein Stück Blech, auf dem es steht. Bei mir ist das ein Turing Pi -Board — ein Mini-ITX-Träger für vier Compute-Module, den ich seinerzeit in der Kickstarter-Kampagne mitfinanziert habe. Die Idee, einen kleinen, lautlosen und stromsparenden Cluster aus austauschbaren Knoten in einem einzigen Gehäuse zu betreiben, hat mich sofort überzeugt. Diese Geschichte handelt davon, wie aus der ersten, etwas naiven Bestückung über ein paar Umwege die heutige Basis von hydra wurde.