Mein OpenClaw-Setup: Eine Box, die Websites bauen kann

Die Website, die du gerade liest, wird von KI-Agenten gepflegt, die auf einer kleinen Linux-Box bei mir zu Hause laufen — und das ganze Arrangement ist so gebaut, dass sie echte Arbeit leisten können, ohne jemals etwas kaputt machen zu können.

Zuerst der selbstbeweisende Teil: Dieser Artikel wird einmal pro Woche von genau dem Setup aktualisiert, das er beschreibt. Ein geplanter Job weckt einen OpenClaw-Agenten, der liest diese Seite neu, korrigiert alles Veraltete, führt die Guard-Checks aus und stempelt das Ergebnis ab. Das Datum „Updated” oben auf dieser Seite wird von genau diesem wöchentlichen Job geschrieben — niemand tippt es ein. Wenn dieses Datum aktuell ist, ist die in diesen Diagrammen gezeigte Pipeline in den letzten sieben Tagen komplett von Anfang bis Ende gelaufen.

Die ganze Box auf einen Blick

Alles läuft auf einer einzigen Maschine. Modelle liefern Tokens — heutzutage meist über DeepSeeks günstige Cloud-API, mit lokalen Modellen als Fallback —, das OpenClaw-Gateway macht daraus Agenten mit Tools, die Agenten bearbeiten reinen Text-Content, ein deterministischer Generator baut die Website, und ein einziges abgesichertes Skript ist der einzige Weg zum Server.

Was am Ende dabei herauskommt

Der Endzustand, bevor überhaupt über das Setup geredet wird:

• „Schreib mir einen Entwurf über X” im Chat → ein Agent schreibt einen Markdown-Artikel in den content/-Ordner der Website, hält sich dabei an das Frontmatter-Schema und den Hausstil der Seite und baut die lokale Vorschau neu.
• „Deploy es” → der Agent führt das Deploy-Skript aus, das standardmäßig ein Dry-Run ist: Es zeigt genau, welche Dateien sich auf dem Server ändern würden, und rührt nichts an. Für die echte Veröffentlichung braucht es ein explizites --go von mir, und selbst dann macht das Skript zuerst ein serverseitiges Backup und löscht niemals etwas.
• Einmal pro Woche weckt ein geplanter Job einen Agenten, der die Website auffrischt — veraltete Daten korrigiert, schwache Artikel verbessert, Links prüft —, wobei Guard-Checks laufen, bevor irgendetwas veröffentlicht werden kann (Details dazu in Schritt 3).
• laserlloyd.com selbst wird genau so verwaltet.

Genau diese Arbeitsteilung ist der Punkt: Die Agenten tippen, die Skripte erzwingen die Regeln, und ich treffe die eine Entscheidung, die zählt — ob eine Änderung live geht.

Hardware und Betriebssystem: jede Linux-Box funktioniert

Ich benutze einen Mini-PC mit viel Unified Memory, weil ich gerne große Modelle lokal laufen lasse (der komplette Stack steht in meinem Begleitartikel, Acht KI-Agenten, eine AMD-Box). Aber speziell für Website-Management sind die Anforderungen bescheiden:

• Jede 64-Bit-Linux-Maschine — ein Mini-PC, ein alter Desktop, sogar ein potentes Laptop. 16 GB RAM reichen für kleine lokale Modelle problemlos; ab 32 GB werden mittelgroße Modelle möglich, die spürbar besser formulieren.
• Eine Distribution mit systemd (praktisch alle) — die Zeitplanung und Dienstüberwachung weiter unten setzen das voraus.
• Python 3 für den statischen Website-Generator, rsync + SSH für Deploys.

Eine GPU brauchst du nicht zwingend. Kleine instruction-getunte Modelle laufen für Entwürfe und Textbearbeitung auch auf der CPU noch akzeptabel. Aber ich bin ehrlich, wo ich nach Monaten mit beiden Ansätzen gelandet bin: DeepSeeks Cloud-API ist inzwischen der Haupttreiber meines gesamten OpenClaw-Setups. Die offenen lokalen Modelle waren der ursprüngliche Plan, und sie laufen noch, aber die Kompromisse summieren sich — minutenlange Ladezeiten für Modelle, VRAM-Jonglage zwischen Diensten und spürbar weniger Intelligenz als ein spitzenmäßig günstiges Cloud-Modell, das Bruchteile eines Cents pro Nachricht kostet. Lokal ist meine Fallback- und Privatsphäre-Stufe, nicht mein täglicher Fahrer. (Die echte monatliche Rechnung: etwa 24 $.)

Schritt 1: ein Agent-Gateway und ein lokales Modell installieren

Zwei Teile: etwas, das ein Modell über eine OpenAI-kompatible API bereitstellt, und etwas, das dieses Modell in einen Agenten verwandelt — mit Tools, Dateizugriff und geplanten Jobs.

Modellserver. LM Studio, Ollama oder der Server von llama.cpp funktionieren alle. Egal, für welchen du dich entscheidest — betreibe ihn als systemd-User-Dienst, damit er Neustarts übersteht:

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # sanity check

Agent-Gateway. Ich verwende OpenClaw, ein offenes, selbstgehostetes Gateway, das benannten Agenten Tools gibt (Shell, Datei-Lese-/Schreibzugriff, Websuche), jeden Agenten auf ein Modell routet (lokal oder Cloud, mit Fallbacks) und eine Chat-Oberfläche bereitstellt. Installiere es, richte einen „Webmaster”-Agenten auf dein lokales Modell aus und gib ihm Tool-Zugriff, der auf das Verzeichnis der Website beschränkt ist. Zwei Konfigurationsregeln sind dabei wichtig, egal welches Gateway du wählst:

• Binde das Gateway an Loopback und sichere jede Chat-Oberfläche mit Authentifizierung ab. Ein Agent mit Shell-Zugriff ist nichts, was man offen im Netzwerk stehen lässt.
• Beschränke das Arbeitsverzeichnis des Agenten auf das Site-Repository. Er soll content/ bearbeiten, nicht dein Home-Verzeichnis.

Zwei Stufen: lokale Agenten fürs Tagesgeschäft, ein starkes Cloud-Modell für Reparaturen

Eine Box, zwei Stufen an Denkleistung. Die OpenClaw-Agenten — auf DeepSeeks günstiger API, mit lokalen Modellen im Hintergrund — erledigen die alltägliche Arbeit mit hohem Volumen: Entwürfe, Bearbeitung, Link-Checks, das wöchentliche Auffrischen. Aber wenn das System selbst kaputtgeht (eine Config-Regression, ein abgestürztes Gateway, ein Build, der nicht laufen will), eskaliere ich zu einem starken Cloud-Coding-Modell, das die ganze Box wie einen Patienten behandelt. Diese Geschichte habe ich separat aufgeschrieben in Wenn OpenClaw kaputtgeht, repariere ich es mit Claude Code: Die OpenClaw-Agenten sind die Belegschaft, das starke Coding-Modell ist der Mechaniker.

Die Crew: jeder Bot auf der Box

Das Gateway hostet ein Aufgebot benannter Agenten, jeder auf das Modell geroutet, das zu seiner Aufgabe passt. Sie alle tauchen in DisPatch auf, der Chat-App, die die Familie nutzt — aber nicht alle in beiden Modi: DisPatchs PIN-Sperre teilt das Aufgebot in eine sichere, immer verfügbare Gruppe und eine Vollzugriffs-Gruppe, die erst nach dem Entsperren erscheint.

Bot	Aufgabe	Läuft auf	DisPatch (gesperrt)	DisPatch (entsperrt)
Bits	Empfang — der Agent, mit dem du sprichst; versteht die Anfrage und schickt sie an den richtigen Spezialisten weiter	DeepSeek flash (Cloud)	—	✔
Brains	Der Grübler — Spezifikationen, Audits, alles, wofür sich Warten lohnt	DeepSeek reasoner (Cloud)	—	✔
Flash	Schnelle Jobs und geplante Nachfassaktionen — der Wachhund, der überfälliger Arbeit hinterherjagt	DeepSeek flash (Cloud)	—	✔
Hermes	Die Brücke zum Coding-Agenten — delegierte Programmierarbeit	DeepSeek (Cloud)	—	✔
Doxy	Lokales Arbeitspferd — Massen- und private Jobs, die das Haus nicht verlassen sollen	122B lokales Modell (vLLM)	—	✔
Charley	Vision — „Was ist auf diesem Foto?", bildbezogene Aufgaben	Gemma 31B (lokal, LM Studio)	✔	✔
Alpha & Beta	Familientaugliche Allgemein-Helfer — Hausaufgabenfragen, Alltagsplausch	DeepSeek flash (Cloud)	✔	✔
Terminex	Kein Agent — DisPatchs Reasonix-Coding-Terminal, ein echtes PTY im Browser	DeepSeek (Cloud)	—	✔

Wie sie in der Praxis abschneiden, ehrlich gesagt:

• Die DeepSeek-gestützten Bots sind die täglichen Arbeitspferde. Flash-Stufe-Agenten (Bits, Flash, Alpha, Beta) antworten in Sekunden, kosten Bruchteile eines Cents pro Nachricht und brauchen nie ein Aufwärmen. Brains, auf der Reasoner-Stufe, braucht pro Antwort spürbar länger — das ist der Punkt, ihm gibst du die Probleme, die es wert sind, durchdacht zu werden — und kostet trotzdem nur Cent-Beträge pro Sitzung. Die gemessene Rechnung für den ganzen Stack steht im Kostenartikel.
• Die lokalen Bots sind langsamer und dümmer, aber privat und kostenlos. Doxys 122B-Modell braucht Minuten, um ins Gedächtnis geladen zu werden, und seine langen Antwortrunden können noch mal mehrere Minuten dauern; die Timeouts des Gateways mussten eigens dafür erhöht werden. Charleys Vision-Modell ist die Ausnahme, die ständig beschäftigt bleibt — Bildbeschreibung ist etwas, das hier keine günstige Cloud-Stufe macht, also verdient sich ein lokales Modell seinen VRAM.
• Die sichere Gruppe ist bewusst langweilig. Alpha, Beta und Charley bilden das Aufgebot im gesperrten Modus: allgemeine Infos und Vision, keine Tools, die Dateien oder Systeme berühren. Genau das macht es zur Nebensächlichkeit, einem Kind ein Handy in die Hand zu drücken.

Schritt 2: eine statische Website plus ein abgesichertes Deploy-Skript

Agenten und WordPress vertragen sich schlecht — eine Datenbank, ein Login, Plugins und PHP sind allesamt Angriffsfläche und allesamt Fehlerquellen. Ein statischer Website-Generator ist der natürliche Partner für einen Agenten: Die gesamte Website besteht aus reinen Textdateien in einem Ordner, der Build ist ein einziger Befehl, und „veröffentlichen” ist ein Dateikopiervorgang. Mein Generator besteht aus ein paar Hundert Zeilen Python (Jinja2 + Markdown + YAML); Hugo, Eleventy oder Zola funktionieren genauso. Worauf es ankommt, ist der Vertrag:

• Inhalt sind Markdown-Dateien mit Frontmatter. Ein LLM bearbeitet diese nativ, und ein git diff zeigt genau, was es getan hat.
• Der Build ist deterministisch. Gleicher Inhalt rein, byte-identische Website raus — jede Änderung an der Ausgabe lässt sich also auf eine Inhaltsänderung zurückführen.
• Es gibt genau einen Deploy-Weg, und der ist ein Skript mit eingebauter Sicherheit, keine Anweisungssammlung, der der Agent einfach vertrauensvoll folgen soll.

Der letzte Punkt ist das Herzstück des ganzen Setups. So sieht meins aus:

./deploy.sh preflight   # checks SSH, target webroot, size budget
./deploy.sh             # build + DRY-RUN rsync — prints what would change
./deploy.sh --go        # build + server-side backup + publish + verify

Und das garantiert das Skript, nach Wichtigkeit geordnet:

1. Standardmäßig Dry-Run. Ohne Argumente ausgeführt, kann es den Server niemals verändern. Ein Agent kann es frei ausführen, um mir einen anstehenden Deploy zu zeigen.
2. Löscht nie. rsync läuft ohne --delete. Ein verwirrter Agent kann eine Seite mit einer neueren Version überschreiben; die Website löschen kann er nicht.
3. Sichert zuerst. Mit --go erstellt das Skript ein serverseitiges Tarball des Webroots, bevor irgendeine Datei überschrieben wird (die letzten paar werden aufbewahrt). Schlägt das Backup fehl, bricht der Deploy ab.
4. Fail-closed. Ein fehlendes Manifest, ein unerreichbarer Host oder ein Platzhalter-Konfigwert bricht ab, bevor rsync überhaupt läuft. Quelldateien (Templates, Skripte, Configs) sind hart ausgeschlossen, sodass sie niemals in den öffentlichen Webroot gelangen können.
5. Prüft danach. Es ruft die Live-Homepage ab und grept nach einem Generator-Marker, den der Build einbettet — ein bloßes HTTP 200 kann ein falsch-positives Ergebnis sein, wenn altes Hosting für die Domain noch antwortet.

Der Agent darf den Dry-Run und den Preflight jederzeit ausführen, wann immer er will. Das --go-Flag ist mir vorbehalten. Diese eine Asymmetrie verwandelt den Gedanken „eine KI hat SSH-nahen Zugriff auf meine Live-Website” von beängstigend in langweilig.

Schritt 3: wöchentliche geplante Updates, mit Leitplanken

Das letzte Puzzleteil macht das Ganze selbsterhaltend. Ein systemd-Timer feuert einmal pro Woche und gibt dem Agenten einen Standardauftrag: die Website durchsehen, alles Veraltete auffrischen, schwache Artikel straffen, interne Links prüfen und das Ergebnis staged — nicht veröffentlicht. Genau dieser Job pflegt auch diesen Artikel: Ein Teil seines Auftrags lautet „den OpenClaw-Setup-Artikel neu lesen, alles korrigieren, was von der Realität abgewichen ist, und das Datum updated: abstempeln.” Das Datum oben auf dieser Seite ist genau dieser Stempel.

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

Der Dienst, den er auslöst, ruft die API (oder CLI) des Gateways mit dem Auftrag auf und führt dann die Guard-Checks auf allem aus, was der Agent gestaged hat:

• Secret-Scan. Ein Muster-Scan über den Diff nach allem, was wie ein API-Key, Token, Passwort oder privater Hostname aussieht. Tools wie gitleaks können das von Haus aus. Jeder Treffer bricht den Lauf ab — fail-closed, keine Ausnahmen.
• Professionalitäts-Check. Ein zweiter LLM-Durchlauf, mit einem anderen Prompt als der Autor, prüft die gestagten Änderungen anhand einer einzigen Frage: „Wäre einem Unternehmen wohl dabei, das zu veröffentlichen?” Tonfall, Behauptungen, unfertige TODOs, Platzhaltertext. Bei einem Fehlschlag bleiben die Änderungen zur menschlichen Überprüfung gestaged, statt deployt zu werden.
• Der Build muss durchlaufen, einschließlich des Link-/Asset-Checkers — ein kaputtes Bild oder ein toter interner Link lässt den Lauf scheitern, bevor er je das Deploy-Skript erreicht.

Erst wenn alle drei bestehen, macht der Job überhaupt einen Dry-Run-Deploy — und auf dieser Website wartet die tatsächliche Veröffentlichung weiterhin auf mein --go. Solltest du der Pipeline irgendwann genug vertrauen, um den wöchentlichen Job autonom veröffentlichen zu lassen, begrenzen die Guards zusammen mit dem nie-löschenden, backup-zuerst-Deploy-Skript den Schaden auf „ein schlechter Artikel ging live, und ich habe aus dem Backup wiederhergestellt.”

Das Ganze nachbauen

Alles oben Beschriebene lässt sich aus dieser Beschreibung nachbauen — nichts davon ist proprietär. Das Rezept, verdichtet:

1. Wähle eine Linux-Box und installiere einen lokalen Modellserver (LM Studio, Ollama, llama.cpp) als systemd-Dienst.
2. Installiere ein Agent-Gateway (OpenClaw oder ähnlich), gebunden an Loopback; erstelle einen Webmaster-Agenten mit Datei-/Shell-Tools, die auf das Site-Verzeichnis beschränkt sind.
3. Migriere die Website auf einen statischen Generator, falls noch nicht geschehen — Markdown-Inhalt rein, ein Build-Befehl raus.
4. Schreibe das abgesicherte Deploy-Skript mit den fünf oben genannten Garantien: Dry-Run als Standard, keine Löschungen, Backup zuerst, Fail-Closed, Verifikation nach dem Deploy. Das ist der Teil, der die meiste Sorgfalt verdient; er umfasst vielleicht 150 Zeilen Bash.
5. Füge den wöchentlichen Timer und die zwei Guard-Checks (Secret-Scan + LLM-Inhaltsprüfung) hinzu, fail-closed.
6. Behalte --go in menschlicher Hand, bis die Pipeline sich etwas anderes verdient hat.

Der Konvention dieser Website entsprechend meint die Box „das selbst umsetzen” oben im Artikel genau das, was sie sagt: Dieser Beitrag ist absichtlich detailliert genug, dass du den ganzen Artikel deinem eigenen LLM geben und es bitten kannst, jeden Teil für deine Website zu bauen. Die Garantieliste des Deploy-Skripts ist im Grunde schon seine Spezifikation.

Stolperfallen

• Das Deploy-Skript muss der einzige Weg sein. Sobald du (oder ein Agent) „nur dieses eine Mal” von Hand ein rsync zusammenbastelt, hast du genau den Vorfall geschaffen, den das Skript verhindern sollte. Meins schließt Quelldateien hart aus und verweigert Platzhalter-Configs genau deshalb, weil ein einmaliger Befehl das nicht täte.
• Ein bloßes HTTP 200 ist kein erfolgreicher Deploy. Während meiner WordPress-Migration antwortete das alte Hosting weiterhin für die Domain — jede „Verifikation” bestand, während die neuen Dateien ungenutzt herumlagen. Bette einen Generator-Marker in deinen Build ein und grepe die Live-Seite danach.
• Agenten folgen dem Schema, das du ihnen zeigst — inklusive der TODOs. Wenn dein Artikel-Grundgerüst Platzhaltertext enthält, veröffentlicht ein faules Modell TODO: excerpt here wortwörtlich. Das ist die halbe Erklärung, warum es den Professionalitäts-Check gibt.
• Lass den Autor nicht sich selbst überprüfen. Gleiches Modell, gleicher Prompt, gleiche blinde Flecken. Der Reviewer braucht mindestens einen anderen Prompt, im Idealfall ein anderes Modell.
• Geplante LLM-Jobs brauchen Timeouts und einen „gestaged, nicht veröffentlicht”-Standard. Ein wöchentlicher Job, der unbeaufsichtigt veröffentlichen kann, wird irgendwann sonntags um 6 Uhr morgens etwas Merkwürdiges veröffentlichen. Staging kostet dich nichts außer einem Review.
• Secret-Scans gehören in die Pipeline, nicht in die Anweisungen des Agenten. „Niemals Secrets einbauen” in einem Prompt ist ein Wunsch; ein fail-closed-Scan auf dem Diff ist eine Kontrolle.