KI & Werkzeuge

ClawForge: Was, wenn dein Server-Panel ein KI-Gehirn hätte?

9 min read

Die Serververwaltung dreht sich im Kreis. Wir loggen uns per SSH ein, setzen Befehle ab, schauen auf Dashboards, loggen uns aus. Oder wir nutzen Weboberflächen, die die Maschine wegabstrahieren und uns dafür Formulare und Knöpfe aus den Neunzigern geben. Hosting-Panels wie Plesk und cPanel haben das Problem „mach es klickbar“ gelöst, aber nie das Problem „mach es intelligent“. Sie sind grafische Aufsätze auf Shell-Befehle, mehr nicht.

Ich baue seit einer Weile etwas anderes. ClawForge ist eine KI-native Plattform zur Serververwaltung, bei der die zentrale Oberfläche weder Dashboard noch Terminal ist. Sie ist ein Agent, der Infrastruktur sehen, durchdenken und bearbeiten kann wie ein erfahrener Systemadministrator — nur eben auch um drei Uhr nachts, wenn der Melder losgeht.

Woran die heutigen Werkzeuge kranken

Jedes Hosting-Panel, jedes Infrastruktur-Dashboard und jedes Überwachungswerkzeug teilt denselben Grundentwurf: Es zeigt Daten, und ein Mensch deutet sie. Die CPU steht bei 94 %? Ein Mensch entscheidet, ob das normal ist. Die Platte läuft voll? Ein Mensch überlegt, welche Protokolle rotiert gehören. Ein Deploy ist fehlgeschlagen? Ein Mensch liest den Fehler, gleicht ihn mit der Konfiguration ab und repariert ihn.

Das funktionierte bei fünf Servern. Bei fünfzig bricht es. Bei fünfhundert ist es absurd. Die Antwort der Branche lautet seit Jahren „mehr Dashboards, mehr Alarme, mehr Runbooks“. Also mehr menschliche Aufmerksamkeit — die einzige Ressource, die sich nicht skalieren lässt.

Das zweite Problem ist die Zersplitterung. Einen heutigen Stack zu betreuen heißt, zwischen Hosting-Panel, CI/CD-Dashboard, Überwachungswerkzeug, Log-Sammler, Container-Registry, DNS-Anbieter und SSL-Verwaltung hin und her zu springen. Jedes mit eigener Oberfläche, eigenem Denkmodell, eigener Anmeldung. Der gedankliche Aufwand, für die Analyse eines einzigen Problems zwischen sechs Werkzeugen zu wechseln, ist enorm.

Was ClawForge ist

ClawForge ist eine Plattform, die einen KI-Agenten zwischen dich und deine Infrastruktur stellt. Kein Chatbot, der dir Shell-Befehle zum Kopieren ausgibt, sondern ein Agent mit echtem Zugriff: Er liest den Serverzustand, führt Befehle aus, ändert Konfigurationen, rollt Code aus und beobachtet das Ergebnis. Er arbeitet in einer abgeschotteten Cloud-Desktop-Umgebung mit vollem Zugriff auf Browser, Terminal und Dateisystem.

Die Kernarchitektur:

  • Abgeschottete Worker-Umgebungen. Jede Verwaltungssitzung läuft in einem eigenen Sandbox-Container mit vollständigem Linux-Desktop. Der Agent hat einen echten Browser, ein echtes Terminal, echte Werkzeuge. Er simuliert keine Handlungen — er führt sie in einer Umgebung aus, die der eines Menschen gleicht.
  • Visuelles Verständnis. Der Agent kann Bildschirmfotos aufnehmen, Bedienelemente erkennen und mit webbasierten Verwaltungsoberflächen umgehen. Damit arbeitet er mit jedem vorhandenen Werkzeug zusammen, nicht nur mit solchen für die Kommandozeile. Er kann durch dein Proxmox-Dashboard navigieren, durch deine Grafana-Ansichten, durch die Oberfläche deiner CI-Pipeline.
  • MCP-Brücke (Model Context Protocol). Externe KI-Werkzeuge, darunter Claude Code, können sich mit ClawForge-Workern verbinden und sie programmgesteuert bedienen. Damit wird ClawForge zu einem Unterbau, durch den jeder KI-Agent arbeiten kann.
  • Snapshot und Rückweg. Vor jeder möglicherweise zerstörerischen Operation sichert der Agent den Worker-Zustand. Geht etwas schief, ist der Rückweg sofort da. Dieses Sicherheitsnetz macht autonomes Arbeiten überhaupt vertretbar.

Die Vorstellung: KI-native Infrastrukturverwaltung

Was tut ein erfahrener Infrastrukturingenieur eigentlich? Er setzt nicht bloß Befehle ab. Er beobachtet den Systemzustand, bildet Hypothesen, prüft sie, entscheidet auf Basis von Zusammenhang und Erfahrung und kontrolliert das Ergebnis. Er weiß, dass ein Lastanstieg dienstags um 14 Uhr normal ist (der tägliche Stapellauf), um zwei Uhr nachts aber nicht. Er weiß, dass „Platte voll“ auf der Protokollpartition bedeutet, dass die Rotation kaputt ist — und nicht, dass eine größere Platte fehlt.

ClawForge ist darauf angelegt, genau diese Denkschleife abzubilden, nicht nur die Befehlsausführung:

  1. Beobachten. Der Agent verbindet sich mit der Infrastruktur, liest den aktuellen Zustand, prüft Messwerte, sieht sich die jüngsten Änderungen an.
  2. Einschätzen. Aus dem aktuellen Zustand und dem geschichtlichen Zusammenhang — frühere Vorfälle, bekannte Muster, Konfigurationsgrundlinien — bestimmt er, was Aufmerksamkeit braucht.
  3. Planen. Bevor er handelt, formuliert er einen Plan und führt ihn je nach eingestellter Autonomiestufe entweder aus oder legt ihn zur Freigabe vor.
  4. Handeln. Er führt die Operation in seiner abgeschotteten Umgebung aus, mit voller Einsicht in jeden Schritt.
  5. Prüfen. Danach kontrolliert er das erwartete Ergebnis. Ist der Dienst wieder da? War der Deploy erfolgreich? Normalisieren sich die Messwerte?

Konkrete Anwendungsfälle

Das ist nicht theoretisch. Auf diese Abläufe arbeite ich hin, teils laufen sie schon:

Websites ausrollen und betreuen

Statt einen Webserver über ein Panel zu konfigurieren, beschreibst du, was du willst: „Rolle dieses Repository als PHP-Anwendung aus, mit MariaDB-Datenbank, SSL-Zertifikat und täglicher Sicherung.“ Der Agent legt den vHost an, konfiguriert den Webserver, richtet die Datenbank ein, installiert SSL, plant die Sicherung und prüft, dass alles läuft. Hat die Anwendung besondere Anforderungen — eine bestimmte PHP-Version, bestimmte Erweiterungen, Cronjobs —, liest der Agent die Konfigurationsdateien des Projekts und richtet sich danach.

Wenn im Produktivbetrieb etwas kaputtgeht, wühlst du dich nicht von Hand durch Protokolle. Du sagst ClawForge „die Seite liefert 502er“, und es untersucht: prüft den Zustand des Webservers, liest die Fehlerprotokolle, findet den Ausfall im Upstream und behebt ihn entweder oder sagt dir genau, was los ist und welche Möglichkeiten es gibt.

Server härten und absichern

Härtung ist mühsam, gleichförmig und zugleich hochwichtig. Genau die Art Arbeit also, in der ein KI-Agent stark ist: einen bekannten Satz bewährter Regeln anwenden, jede einzeln prüfen, Abweichungen melden. ClawForge kann einen Server gegen eine Sicherheitsgrundlinie prüfen — SSH-Konfiguration, Firewall-Regeln, Paketstände, offene Dienste, Dateirechte —, Korrekturen anwenden und einen Bericht erzeugen. Kein einmaliger Scan, sondern laufende Überwachung mit automatischer Korrektur bei allem, was nachweislich gefahrlos ist.

Orchestrierung über mehrere Server

Die eigentliche Stärke zeigt sich bei mehreren Servern. Eine Konfigurationsänderung über eine Flotte auszurollen heißt: Der Agent verbindet sich mit jeder Maschine, wendet die Änderung an, prüft das Ergebnis und geht weiter. Scheitert eine Maschine, hält er an, meldet das Problem und wartet auf Anweisung, statt blind weiterzumachen. Er versteht, dass ein fehlgeschlagenes apt upgrade auf Maschine 3 von 20 „anhalten und nachsehen“ bedeutet und nicht „nochmal versuchen und hoffen“.

Überwachung und Störungsbearbeitung

Herkömmliche Überwachung sagt dir, dass etwas nicht stimmt. ClawForge untersucht, warum. Schlägt ein Alarm an, kann der Agent sofort mit der Diagnose beginnen, die auch ein Mensch führen würde: Dienstzustand prüfen, jüngste Ausrollungen ansehen, Ressourcennutzung untersuchen, einschlägige Protokolle lesen und über Systeme hinweg in Beziehung setzen. Wenn du auf den Vorfall schaust, ist er bereits eingeordnet — mit wahrscheinlicher Ursache und Lösungsvorschlag.

Warum nicht einfach Ansible, Terraform oder Pulumi?

Infrastructure-as-Code-Werkzeuge sind hervorragend in dem, was sie tun: einen Sollzustand beschreiben und darauf zulaufen. ClawForge ersetzt sie nicht. Es ist die Schicht darüber.

Ansible kann ein Playbook anwenden. Es kann nicht entscheiden, welches Playbook zu einer vage beschriebenen Störung passt. Terraform kann Infrastruktur bereitstellen. Es kann nicht ergründen, warum die bereitgestellte Infrastruktur sich seltsam verhält. Diese Werkzeuge gießen menschliche Entscheidungen in Automatisierung. Bei ClawForge geht es darum, mehr dieser Entscheidungen selbst zu treffen.

In der Praxis wird ClawForge Werkzeuge wie Ansible und Terraform als seine Hände benutzen. Der Agent schreibt das Playbook, führt es aus und prüft das Ergebnis. Die Intelligenz liegt in der Entscheidung, nicht in der Ausführung.

Die Architektur im Unterbau

ClawForge läuft auf einem schlichten, aber bewusst gewählten Stack:

  • Worker-Container auf Basis schlanker Linux-Abbilder mit vollständiger Desktop-Umgebung (Xfce oder kopflos mit virtuellem Framebuffer). Jeder Worker ist abgeschottet und wegwerfbar.
  • Ein Koordinierungsdienst (Caddy plus eigene Anwendung), der Lebenszyklus, Anmeldung und Routing der Worker verwaltet.
  • Eine MCP-Brücke, die die Fähigkeiten der Worker nach außen an KI-Agenten weiterreicht. Das ist der Anschlusspunkt: Jedes MCP-fähige KI-Werkzeug kann sich mit einem ClawForge-Worker verbinden und ihn als Ausführungsumgebung nutzen.
  • PostgreSQL für Zustandsverwaltung, Prüfprotokoll und Sitzungsverlauf.
  • Snapshot-Speicher zur Sicherung des Worker-Zustands und für den Rückweg.

Die Worker selbst laufen in Proxmox-LXC-Containern. Das gibt uns die Abschottung von Containern bei einer Geschwindigkeit nahe am blanken Blech. Kein Docker im Docker, keine Kubernetes-Komplexität. Nur schlanke Container, die in Sekunden hochkommen und im Leerlauf fast nichts kosten.

Was „Unterbau für Websites“ tatsächlich heißt

Die ehrgeizige Vorstellung lautet: ClawForge wird für Web-Infrastruktur das, was heute ein Hosting-Panel ist — nur intelligent. Statt dich durch Formulare zu klicken, um eine Seite anzulegen, beschreibst du, was du brauchst. Statt Dokumentation zu lesen, um einen komplizierten Aufbau zu konfigurieren, erklärst du die Anforderungen, und der Agent setzt sie um.

Für Webagenturen, die Dutzende Kundenseiten betreuen, ändert das das Betriebsmodell. Ein einzelner Ingenieur kann mit ClawForge eine Infrastruktur führen, für die es heute ein Team braucht. Nicht weil das Werkzeug einfache Dinge schneller erledigt, sondern weil es die komplizierte, zusammenhangsabhängige Arbeit übernimmt, für die bisher bei jeder Entscheidung Erfahrung auf Senior-Niveau nötig war.

Der Fahrplan:

  • Phase 1 (aktuell): Verwaltungssitzungen mit einem Worker. Mit einem Server verbinden, Aufgaben erledigen, trennen. Der Agent als geschicktes Paar Hände.
  • Phase 2: Dauerhafte Serververbindungen mit laufender Überwachung. Der Agent behält den Zustand der Infrastruktur auch zwischen den Sitzungen im Blick.
  • Phase 3: Orchestrierung über mehrere Server mit regelbasierter Autonomie. Festlegen, was der Agent ohne Freigabe darf (einen abgestürzten Dienst neu starten) und was eine menschliche Unterschrift braucht (eine Produktivdatenbank ändern).
  • Phase 4: Der komplette Lebenszyklus der Infrastruktur. Bereitstellen, Ausrollen, Skalieren, Störungen bearbeiten, Abschalten — alles über eine dialogische Oberfläche mit echter Ausführungsfähigkeit dahinter.

Die Wette

Die Wette hinter ClawForge ist einfach: Das Hosting-Panel als Produktkategorie steht vor dem Umbruch. Nicht durch ein besseres Panel mit hübscherer Oberfläche, sondern durch ein grundlegend anderes Zusammenspiel, in dem der KI-Agent der eigentliche Bediener ist und der Mensch die Aufsicht führt. Das Panel braucht keine besseren Knöpfe. Es muss aufhören, ein Panel zu sein.

Woche für Woche werden die zugrunde liegenden KI-Modelle besser im Schlussfolgern, im Umgang mit Werkzeugen und in der mehrstufigen Planung. Der Abstand zwischen „Agent, der in einer simulierten Umgebung Knöpfe drückt“ und „Agent, der Produktivinfrastruktur führt“ schrumpft schneller, als die meisten in der Hosting-Branche wahrhaben wollen. ClawForge entsteht, um bereit zu sein, wenn dieser Abstand ganz verschwindet.

Zur MCP-Brücke, zur Worker-Architektur und zu einzelnen Automatisierungsabläufen werde ich technische Details nachreichen, während die Plattform wächst. Wer Infrastruktur betreut und vom heutigen Werkzeugdenken genug hat, sollte hier mitlesen.