Fulling: ein Agenten-Frontend mit Kubernetes-Grenze

Ein Fundament statt eines Produkts: das Problem hinter Fulling

Die meisten Agenten-Projekte lösen das Modellproblem und lassen die Infrastruktur offen. Fulling setzt an der anderen Stelle an. Das Repository beschreibt das Ziel als dauerhafte Arbeitsumgebungen, die Skills, Dateien, Gedächtnis, Skripte und Laufzeit zusammenführen. Der aktuelle v3-Stand liefert davon nur den Rand: Identität und eine Kubernetes-Zugangsgrenze. Wer die README liest, findet eine explizite Aussage darüber, was noch fehlt. Der benutzerspezifische Kubeconfig sei nicht das endgültige Ownership-Modell der Workspace-Runtime. Das ist eine ungewöhnlich offene Formulierung für ein Projekt dieser Art und zugleich die wichtigste Information für jeden, der einen Produktiveinsatz erwägt. Adressaten sind Entwickler und kleine Teams, die Agenten nicht als SaaS einkaufen, sondern auf eigener Infrastruktur betreiben wollen. Der Anspruch reicht über eine Chat-Oberfläche hinaus: Wer einem Agenten einen Kubernetes-Kontext gibt, will, dass er Ressourcen anlegen, prüfen und wieder entfernen kann. Fulling liefert dafür die Anmeldung, die Speicherung und die Validierung der Zugangsdaten. Alles, was danach kommt, ist in docs/architecture.md beschrieben und im Code noch nicht vorhanden.

Wie die Kette von der Anmeldung bis zum API-Server aussieht

Der sichtbare Datenfluss ist kurz. Better Auth übernimmt die Anmeldung, und laut README ist GitHub der einzige Weg hinein. Nutzer, Provider-Konten und Sitzungen liegen in PostgreSQL, verwaltet über Prisma. Ein geschützter Einstiegspunkt in den Arbeitsbereich prüft die Sitzung. Danach kommt der Teil, der Fulling von einem gewöhnlichen Dashboard unterscheidet: Pro Nutzer wird genau ein Kubeconfig gespeichert, im Klartext. Bevor dieser Kontext irgendwo verwendet wird, läuft er durch eine Validierung, die gegen den Kubernetes-API-Server ein SelfSubjectReview absetzt. Das ist ein sauberer Schnitt, weil die Prüfung nicht auf dem Parsen der Datei bleibt, sondern den Server selbst fragt, welche Identität er sieht. Fällt die Antwort anonym aus, wird der Kontext abgelehnt. Erst danach entsteht ein Kubernetes-Client, der auf den angemeldeten Nutzer beschränkt ist. Die Validierung filtert zusätzlich ausführbare Credential-Plugins, auth-provider-Plugins, lokale Dateifelder, Proxy-Konfiguration, nicht-HTTPS-API-Server und Weiterleitungen. Das ist eine bewusst enge Allowlist, und sie erklärt, warum das Projekt als Fundament und nicht als Feature-Sammlung auftritt.

Was die Validierung bewusst nicht verhindert

Ein authentifizierter Nutzer darf laut README weiterhin einen HTTPS-API-Server auf einer beliebigen Netzwerkadresse eintragen. Das Dokument benennt die Konsequenz selbst: Die Grenze gegen ausgehende Anfragen und SSRF ist eine ausdrückliche Deployment-Entscheidung, keine im Code erzwungene Eigenschaft. Für Betreiber heißt das, dass die Netzwerkebene die Arbeit machen muss. Wer Fulling in einem Cluster betreibt, in dem der Anwendungspod die Steuerungsebene oder interne Dienste erreichen kann, hat sich mit der eigenen Konfiguration ein Problem geschaffen, das das Projekt nicht abfängt. Die zweite offene Flanke betrifft die Speicherung. Kubeconfigs liegen im Klartext in PostgreSQL, und die README formuliert den Zusammenhang ohne Beschönigung: Lesezugriff auf die Datenbank bedeutet Zugriff auf die Kubernetes-Zugangsdaten der Nutzer. Das ist keine Kleinigkeit, sondern eine Architekturentscheidung mit Folgen für Backups, Replikate, Monitoring-Zugänge und jeden Export. Wer eine Datenbankkopie weitergibt, gibt die Clusterzugänge mit weiter. Dass die browserzugewandten APIs gespeicherte Inhalte nie zurückgeben und Logs keine Tokens, Schlüssel, Zertifikate oder Kubeconfig-Inhalte enthalten dürfen, ist eine Regel, die eingehalten werden muss, nicht eine Eigenschaft, die das System garantiert.

Inbetriebnahme: zwei Wege, ein Befehlssatz

Fulling kennt zwei Betriebsarten, und die Unterscheidung ist wichtig. Die öffentliche Anwendung startet ohne Umgebungsvariablen und ohne Datenbank. Dafür genügen npm ci und npm run dev, und die Anmeldung bleibt abgeschaltet. Wer den authentifizierten Arbeitsbereich testen will, kopiert .env.template nach .env.local, füllt Datenbank-, Better-Auth- und GitHub-Werte aus, führt npm run prisma:migrate aus und startet den Server erneut. Danach läuft die Anwendung unter http://localhost:3000. Der GitHub-OAuth-Callback muss als ${BETTER_AUTH_URL}/api/auth/callback/github eingetragen werden, sonst schlägt der Anmeldefluss fehl. Als Laufzeitumgebung nennt das Repository Node.js 24 einschließlich des mitgelieferten npm 11. Neben den genannten Befehlen existieren npm run build, npm run lint, npm test für Vitest, npm run test:e2e für Playwright sowie prisma:format und prisma:validate. Ein Punkt, der beim Upgrade aus einer bestehenden Installation übersehen werden kann: Diese Version verwendet ein neues Basisschema und migriert keine v2-Daten. Sie muss gegen eine neue oder ausdrücklich zurückgesetzte Datenbank laufen. Und das Zurücksetzen der Fulling-Datenbank löscht keine Kubernetes-Ressourcen, die v2 angelegt hat. Dafür verweist die README auf docs/v2-resource-inventory.md, das vor dem Ersetzen eines v2-Deployments abzuarbeiten ist.

Vercel, Kubernetes und die Frage, wo die Runtime hingehört

Die Deployment-Dokumentation zeigt eine Spannung, die das Projekt selbst nicht auflöst. Fulling lässt sich nativ auf Vercel betreiben, ohne vercel.json, und die öffentliche Anwendung baut und startet ohne Umgebungsvariablen. GitHub-Anmeldung, datenbankgestützter Arbeitsbereich und Kubeconfig-Flows bleiben in diesem Modus deaktiviert, bis die vollständige Konfiguration vorliegt. Das ist ein sinnvoller Standard, denn eine halb konfigurierte Authentifizierung ist schlechter als gar keine. Zugleich ist Vercel nicht die Umgebung, in der ein Agent Kubernetes-Ressourcen verwaltet. Wer den vollen Funktionsumfang will, braucht PostgreSQL in Reichweite, ein GitHub-OAuth-App und einen Ort, von dem aus der API-Server erreichbar ist. Die Topics des Repositories nennen Docker und Kubernetes, die README beschreibt die Infrastruktur jedoch nicht im Detail. Ob es fertige Manifeste, Helm-Charts oder Dockerfiles gibt, lässt sich aus dem vorliegenden Material nicht bestätigen. Wer einen Clusterbetrieb plant, sollte das vor der Entscheidung im Repository selbst nachsehen, statt es aus der Themenliste zu schließen.

Was Fulling nicht ist, und was stattdessen passt

Der Vergleich mit einem Agenten-Framework wie LangChain oder einem Orchestrierungswerkzeug wie Temporal fällt eindeutig aus, weil Fulling eine andere Schicht besetzt. Diese Bibliotheken modellieren Werkzeugaufrufe, Zustandsübergänge und Wiederholungsversuche innerhalb einer Anwendung. Fulling modelliert die Grenze zwischen einem angemeldeten Menschen und einem Cluster, den dieser Mensch steuern darf. Wer nach einem Framework sucht, um Ketten von LLM-Aufrufen zu bauen, wird hier nichts finden. Umgekehrt gilt derselbe Schnitt: Wer bereits ein Kubernetes-Dashboard mit RBAC und ServiceAccount-Token betreibt, braucht Fulling nicht, um Zugriff zu verwalten. Der Unterschied liegt im Modell. Ein Dashboard bindet Identitäten an Cluster-Rollen und überlässt die Zuordnung dem Cluster. Fulling speichert pro Nutzer einen vollständigen Kubeconfig in der Anwendungsdatenbank und prüft ihn über SelfSubjectReview. Das ist bequemer für den einzelnen Nutzer und schwächer in der Isolation, weil die Zugangsdaten im Anwendungsspeicher liegen statt im Cluster. Für Einzelentwickler mit eigenem Cluster ist das ein vertretbarer Tausch. Für eine Organisation mit mehreren Teams und Nachweispflichten ist es der falsche Ansatz.

Wartung, Lizenz und der Aufwand beim Versionssprung

Das Repository steht unter MIT, und die Lizenzangabe ist die einzige Lizenzinformation im vorliegenden Material. Für Betreiber bedeutet MIT, dass Weitergabe und Änderung erlaubt sind, sofern der Copyright-Hinweis und der Lizenztext erhalten bleiben. Das ist keine Rechtsberatung, und wer Fulling als Grundlage eines eigenen Produkts verwendet, sollte die konkreten Pflichten selbst prüfen. Der Wartungsaufwand lässt sich an den veröffentlichten Versionen ablesen: v1.0.0 erschien am 30. Januar 2026 als MVP, v2.0.0 am 11. Mai 2026, der letzte Push datiert auf den 17. August 2026. Zwischen v2 und v3 liegt ein Bruch, denn die README spricht von einem neuen Basisschema ohne Migrationspfad und davon, dass das Repository bewusst keine Kompatibilitätsschicht zum vorherigen Produktmodell oder Authentifizierungssystem enthält. Wer v2 betreibt, plant also keinen Upgrade, sondern einen Neuaufbau mit vorheriger Bestandsaufnahme der Kubernetes-Ressourcen. Wer neu einsteigt, startet auf einem Fundament, dessen Zielmodell in docs/architecture.md beschrieben und noch nicht gebaut ist. Genau dort liegt die eigentliche Prüfaufgabe: ob der Workspace-Begriff, den die Dokumentation entwirft, mit dem übereinstimmt, was der Code heute als benutzerspezifischen Kubeconfig umsetzt.

Redaktionelles Fazit

Wer heute eine selbst gehostete Agenten-Oberfläche mit klarer Kubernetes-Anbindung sucht und bereit ist, die Produktreife selbst mitzubringen, findet in Fulling ein schlankes, MIT-lizenziertes Fundament. Wer eine fertige Plattform mit mehreren Nutzern, Rollen und Audit-Trail erwartet, sollte warten. Vor jedem Produktiveinsatz ist zu prüfen, ob die Datenbankzugriffe wirklich auf den Anwendungscode beschränkt sind, denn das Repository dokumentiert ausdrücklich, dass Lesezugriff auf PostgreSQL gleichbedeutend mit Zugriff auf die Kubernetes-Zugangsdaten aller Nutzer ist.

Offizielle Quellen

1. FullAgent/fulling on GitHub
2. License: MIT
3. Project website
4. README
5. Releases