abualruz-homelab: die Site und die Infra dahinter

Das hier ist das Meta-Projekt: die Site, die du gerade liest, die Homelab-Infrastruktur, die sie spiegelt, und das Agent-Playbook, das beides gebaut hat. Es ist auch, ganz buchstäblich, ein laufendes Experiment: Kann man eine Personal-Site in Produktionsqualität liefern, wenn KI-Coding-Agents die primäre Arbeitskraft sind - und dabei eine Codebase produzieren, für die man sich nicht schämt?

Die Antwort lautet bislang: ja - mit erheblichen Asterisken.

Warum es das gibt

Zwei Gründe. Der erste ist langweilig: Ich brauchte eine Personal-Site. Ich hab das seit Jahren vor mir hergeschoben, und “vor mir herschieben” ist der Friedhof, auf dem Side-Projects einen heimsuchen. Der zweite Grund ist interessanter: Ich wollte ein echtes Projekt - kein Spielzeug, kein Tutorial, kein “Hello World mit Deploy-Button” - um den agent-gestützten Development-Workflow, den ich mit Fulcrum gebaut hatte, ernsthaft zu testen.

Eine Personal-Site ist dafür ideal. Die Anforderungen sind real. Die Design-Entscheidungen sind relevant. Es gibt echten Content zu schreiben, echte Performance-Budgets einzuhalten, echte CSP-Header, die man auf peinliche Art falsch macht und dann fixen muss. Aber der Blast-Radius von Fehlern ist komplett mein eigener - ich kann also schneller vorgehen und sichtbarer scheitern als bei einem Client-Engagement.

Jede Phase wird mit einem Progress-Log und einem Lessons-Doc geliefert. Das ist kein Dokumentations-Theater - diese Docs sind Inputs für den nächsten Agent-Run. Der Chief-of-Staff liest das Lessons-Doc, bevor er Arbeit für Phase N+1 dispatcht. Die Disziplin, das aufzuschreiben, ist die Disziplin, die nächste Phase schneller zu machen.

Wie es funktioniert

Die Site ist Astro 6 mit Svelte 5 für interaktive Islands. Astro tut, was es soll: nahezu null JavaScript für statische Seiten, selective Hydration für die Teile, die sie brauchen. Svelte 5’s Runes-Modell ist wirklich gut - die reaktiven Primitives sind sauberer als React Hooks für die Art kleiner, fokussierter Interaktivität, die eine Personal-Site braucht.

Content sind MDX-Files in einem strukturierten Collection-Schema, das zur Build-Zeit von Zod validiert wird. Topics sind ein Enum (einmal definiert in src/data/topics.ts, von Schema und Hub-Pages gleichermaßen konsumiert), sodass ein Typo in einem Frontmatter-Feld den Build laut scheitern lässt statt still eine 404 zu produzieren. Ich habe Build-Time-Schema-Validierung für Content-Sites wirklich lieben gelernt. Der Feedback-Loop ist schnell, die Fehler sind spezifisch.

Der Homelab-Spiegel läuft auf einer einzelnen Box in meinem Heimnetzwerk hinter einem Caddy Reverse Proxy. Docker Compose verwaltet die Services; Caddy übernimmt TLS-Termination und das Ausliefern der statischen Files. Die Content Security Policy lebt in einer _headers-Datei, die mit den statischen Assets ausgeliefert wird - Caddy reicht sie unverändert durch, was die richtige Aufteilung der Verantwortlichkeit ist.

Deployment ist ein GitHub Actions Workflow, der die Astro-Site baut, den Output auf den Server pusht und den Docker-Service neustartet. Nicht fancy. Muss nicht sein. Die Deploy-Pipeline, die dich clever aussehen lässt, ist meistens die, die um 23 Uhr kaputt geht, wenn du einen Fix rausbringen willst.

Was interessant ist

Das phasenbasierte Shipping-Modell war nicht Teil des ursprünglichen Plans. Es entstand aus dem ersten Agent-Run, der ein Phase-0 produzierte, das kohärenter war als alles, was ich im Voraus hätte designen können - eine minimale viable Site mit einem Content-Schema, einem funktionierenden Build und einer Deploy-Pipeline - plus einem Follow-up-Doc, das die nächsten Schritte auflistete. Diese Struktur hat sich als tragendes Element herausgestellt.

Die interessante Eigenschaft von “jede Phase hat ein Lessons-Doc” ist, dass sie dich zwingt, zu artikulieren was du gelernt hast, bevor du den Kontext komplett vergessen hast. Das klingt offensichtlich, aber in der Praxis passieren die meisten Projekt-Retrospektiven drei Wochen nach der Arbeit, wenn die Details verblasst sind und man Allgemeinheiten produziert. Das Lessons-Doc am selben Tag zu schreiben, an dem die Phase geliefert wird, produziert viel spezifischere Beobachtungen. “Das CSP unsafe-inline Stopgap muss aufgelöst werden, bevor Astros Meta-CSP-Ansatz stabil genug zum Verwenden ist” ist eine nützliche Notiz. “CSP ist kompliziert” ist es nicht.

Die Kombination Svelte 5 + Astro hat mich auch gezwungen, sorgfältig darüber nachzudenken, was interaktiv sein muss und was nicht. Die Standardannahme in moderner Web-Entwicklung ist, dass alles interaktiv ist; Astro dreht das um, und in diesem Constraint zu arbeiten hat eine Site produziert, die schneller ist, als sie geworden wäre, hätte ich nach einem SPA-Framework gegriffen.

Was ich ändern würde

Der Homelab-Spiegel läuft auf einer einzelnen Maschine ohne Failover. Das ist eine bewusste Entscheidung - Komplexität, die man nicht braucht, ist Komplexität, die einen irgendwann beißt - aber es bedeutet auch, dass die Site runtergeht, wenn ich Hardware-Maintenance mache, was häufiger passiert als ich gerne zugebe. Eine zweite Maschine in Active-Passive-Failover mit Caddy als Front Door steht auf der Liste für eine künftige Phase.

Die CSP-Story ist noch work in progress. Die aktuelle _headers-Datei nutzt unsafe-inline als Stopgap, während Astros nativer Meta-Tag-CSP-Ansatz reift. Das ist ein bekanntes Debt-Item, tracked, und es wird geliefert, wenn die Upstream-Situation stabil genug ist.

Was mich für künftige Phasen am meisten interessiert: die Site selbst als Output-Surface für den Agent-Workflow zu nutzen. Im Moment leben die Progress-Logs und Lessons-Docs in Markdown-Files, die ich lese. Was ich will, ist eine strukturierte Agent-Memory-Schicht - Fulcrum, natürlich - die diese Docs als L0-Sources ingestiert und die kuratierten Lessons automatisch aufzeigt, wenn der COS die nächste Phase plant. Die Infra ist schon da. Ich muss nur ordentlich verkabeln.

Das ist das eigentliche Meta-Projekt: die Tools bauen, dann die Tools benutzen, um das Projekt zu bauen, dann die Lessons des Projekts zurück in die Tools einspeisen. Der Loop beginnt sich zu schließen.