Fragon Forge: Vom internen Tool zum Multi-Tenant-SaaS

Auf einen Blick

Die Ausgangssituation

Softwareentwicklung besteht zu einem großen Teil aus repetitiven Aufgaben: Boilerplate schreiben, Dependencies aktualisieren, Code Reviews durchführen, Sicherheitslücken finden. Als Engineering Lab mit Fokus auf Effizienz stellten wir uns die Frage: Was wäre, wenn ein KI-Agent diese Aufgaben eigenständig übernimmt? Direkt im bestehenden Git-Workflow, ohne Umwege?

Die am Markt verfügbaren Lösungen (GitHub Copilot, CodeRabbit, Cursor und Co.) waren entweder an GitHub gebunden, deckten nur Teilbereiche ab oder zwangen Teams in einen Workflow, der mit ihrem bestehenden Forge wenig zu tun hatte. Für Teams mit GitLab, Gitea oder Bitbucket, strikten DSGVO-Anforderungen und Multi-Forge-Setups war keine davon eine echte Lösung.

Wir bauten Fragon Forge zunächst als internes Werkzeug für unsere eigenen Repositories. Nach Monaten produktiven Einsatzes wurde klar: was wir für uns gebaut haben, fehlt vielen anderen Teams genauso. So wurde aus dem internen DevOps-Tool ein eigenständiges Produkt.

Die Herausforderung

Vom internen Tool zum verkaufbaren Produkt zu kommen heißt, mehrere Probleme gleichzeitig zu lösen.

Vier Forge-Provider, ein Workflow. GitHub, GitLab (CE + EE), Gitea/Forgejo, Bitbucket Cloud. Jeder hat eigene APIs, Webhook-Formate und Auth-Mechanismen. Die Abstraktion muss sauber sitzen, sonst skaliert das Engineering nicht.

Code-Generierung und Analyse aus einem Guss. Ein Entwickler beschreibt ein Issue, die KI liefert eine fertige Merge Request. Und prüft sie anschließend selbst auf Security-Issues, Dependency-Schwachstellen und Code-Style.

Fremden Code sicher ausführen. Ein Agent, der Code im Auftrag eines Kunden schreibt, führt zwangsläufig auch dessen Code aus: Tests, Builds, Linter. Auf einer kostenlosen Stufe heißt das täglich hunderte Male beliebigen Code von beliebigen Leuten laufen lassen. Ohne harte Isolation ist das ein Sicherheits-Albtraum.

Volle Datensouveränität. EU-Hosting, BYOK für LLM-Keys (Bring Your Own Key), kein Token-Markup, kein Training auf Kundencode. Wer Fragon Forge nutzt, muss wissen, wo seine Daten liegen und wer sie sieht.

Unsere Lösung: Fragon Forge

Fragon Forge klinkt sich per Webhook in deinen Forge ein. Vier Kernfunktionen.

1. Coding Agent: Vom Issue zur Merge Request

Der Workflow ist denkbar einfach. Ein Entwickler erstellt ein Issue und setzt das Label ai-task (oder ruft den Agent per @fragonforge im Kommentar). Fragon Forge empfängt den Webhook, klont das Repository, ein KI-Agent analysiert das Issue und schreibt den Code. Fragon Forge öffnet automatisch eine Draft Merge Request inklusive eigenständigem Review. Der Entwickler kontrolliert und merged.

Was Sie daraus mitnehmen können: Der Schlüssel zum Erfolg war die Entscheidung, den Agent nicht interaktiv zu gestalten. Statt eines Chatbots, der Rückfragen stellt, bekommt der Agent einmal den vollständigen Kontext und liefert ein Ergebnis. Das reduziert die Latenz drastisch und macht den Workflow asynchron. Der Entwickler muss nicht warten.

2. Static Analysis: Über zwölf Tools, ein Dashboard

Bei jeder Merge Request läuft eine umfangreiche Analyse automatisch: Semgrep und Trivy für Security und Container-Vulnerabilities, Gitleaks für versehentlich committete Secrets, Checkov und trivy config für IaC (Terraform, Kubernetes, Helm, Bicep), dazu ESLint, RuboCop, PHPStan, Ruff, Clippy und Co. für sprachspezifische Checks. Plus Komplexitäts- und Duplikations-Analyse via Lizard und jscpd.

Die Ergebnisse landen in einem Quality Dashboard mit A-F-Rating, Severity-Breakdown und Trend-History. Nur neue Findings blockieren die MR. Die Baseline ist branch-aware, sodass bestehende Schulden den Workflow nicht aufhalten. Findet der Agent etwas, das er selbst fixen kann, triggert das Label autofix-ready einen Auto-Fix-Lauf mit Konvergenzerkennung.

Technischer Insight: Die Analyse-Tools laufen im gleichen sandboxed Lauf wie der Coding Agent, nicht als separate CI-Pipeline. Das hat zwei Vorteile. Die Ergebnisse landen direkt strukturiert in unserer Datenbank (statt als CI-Artefakte, die niemand parst), und das Dashboard kann historische Trends über alle Branches und Repositories hinweg darstellen.

3. Multi-Agent Workflows: Trennung der Verantwortung

Ein einzelner Agent funktioniert bis zu einer gewissen Komplexität, dann beginnt er, sich selbst im Weg zu stehen. Fragon Forge trennt deshalb Planner, Coder und Reviewer. Jeder mit eigener Modellkonfiguration. Für die Planung eignen sich leistungsstärkere Modelle (z.B. Claude Opus), während Coding-Tasks mit schnelleren Modellen (z.B. Claude Sonnet) effizient laufen.

Im Spec-Driven Mode wird die Kette explizit: aus dem Issue wird zuerst eine Spec, dann Tests, dann Code, mit menschlichen Approval Gates dazwischen. Für ganze Projekte gibt es Deep Planning: Discovery, Architektur, Decomposition, Judge-Review.

4. Repo-aware RAG und Persistent Lessons

Der Agent indexiert dein Repository mit tree-sitter und einem Qdrant-Vektorstore, sodass er relevanten Code aus dem gesamten Projekt findet, nicht nur aus der gerade bearbeiteten Datei. Persistent Lessons speichern, was der Agent aus früheren Tasks gelernt hat. Sowohl global als auch repo-spezifisch. Review-Kommentare an einer Fragon-Forge-MR triggern den Agent mit vollem Kontext erneut, sodass Feedback im Loop landet statt im Vergessen.

Was wir verworfen haben: Container-per-Customer

Die erste Version der SaaS-Architektur sah anders aus. Jeder Kunde bekommt einen dedizierten Fragon-Forge-Container mit eigener Datenbank und eigenem Docker-Volume. Die Logik war intuitiv. Physische Trennung ist das einfachste mentale Modell für Isolation. Keine geteilten Zeilen, keine vergessenen WHERE-Klauseln, keine geteilte Queue. Sollte sauber sein.

War es auch. Skaliert aber nicht.

Drei Dinge haben wir unterschätzt.

Free-Tier-Ökonomie. Container-per-Customer heißt: ein Container pro Account, ein Resource-Floor pro Container, egal ob aktiv oder nicht. Auf einem Free Tier, der bewusst niedrigschwellig sein soll (keine Kreditkarte, sofort nutzbar), wird das ein Hosting-Cost-Problem, das den Free Tier ökonomisch unmöglich macht.

Operative Komplexität. Hunderte Container heißt hunderte Update-Pfade, hunderte Health-Checks, hunderte Backup-Streams, hunderte Migrations-Läufe. Caddy als Reverse-Proxy mit Auto-Provisioning, SSO-Bridge zwischen Control Plane und Customer Container, per-Container-Versions-Drift. Jede Operation, die zentral trivial ist, wird zur Choreografie.

Die Isolation, die wir wollten, war eine andere als die, die wir bauten. Datentrennung pro Container löst „kein anderer Account sieht deine Zeilen". Aber das eigentliche Risiko bei einem Coding-Agent ist nicht der Datenbank-Query-Layer, sondern die Tatsache, dass der Agent fremden Code ausführt. Container-per-Customer hilft dagegen exakt nichts. Der Container des Kunden führt sowieso dessen Code aus. Die Isolations-Frage liegt eine Ebene tiefer als die Tenant-Frage.

Die Korrektur war kein Big-Bang-Rewrite, sondern ein schrittweiser Umbau über mehrere Releases. Langsamer als ein Greenfield-Restart, aber jeder Zwischenstand blieb produktionsfähig. Ohne Vertrauensvorschüsse Richtung „beim nächsten Release wird's wieder gut".

Das Ergebnis ist eine geteilte PostgreSQL mit Per-Row-Tenant-Filtern (Datentrennung), ein ephemerer Kubernetes-Job mit gVisor- oder Kata-Sandbox pro Agent-Lauf (Execution-Trennung) und ein MCP-Gateway als einzige Tür aus der Sandbox (Capability-Trennung). Drei Ebenen Isolation, jede für ein anderes Risiko. Und nicht eine davon hätte die Container-per-Customer-Architektur gelöst.

Wie wir Code sicher ausführen

Fragon Forge ist Multi-Tenant by design. Viele Accounts teilen sich eine Anwendung und eine Datenbank. Aber Daten und Agent-Läufe sind durch Konstruktion isoliert, nicht durch Vertrauen.

Datenisolation. Eine PostgreSQL, ein Schema, jede mandantenbezogene Zeile mit der Tenant-ID gestempelt. Die Isolation wird auf der Data-Access-Schicht erzwungen (EF Core Global Query Filters), bei jedem HTTP-Request und jedem Background-Job. Nie über ad-hoc WHERE-Klauseln, die jemand vergessen könnte. Ein Two-Tenant Leak-Test Harness verifiziert die Nicht-Leckage gegen jeden Endpoint, jeden Background-Pfad und jede RAG-Abfrage. Und gated jedes Release.

Ausführungsisolation. Den Agent gegen ein fremdes Repo laufen zu lassen heißt, beliebigen Code auszuführen (Tests, Builds, Skripte). Jeder Agent-Lauf läuft als ephemerer, einmaliger Kubernetes-Job: non-root, Read-Only-Root-Filesystem, gedroppte Capabilities, Seccomp, CPU/RAM/PID/Disk/Timeout-Limits und Default-Deny Network Egress. Free- und Solo-Läufe nutzen gVisor (Kernel-Level-Sandbox), Team-Läufe nutzen Kata Containers (VM-Grade Isolation). Untrusted Agent-Pods werden niemals mit Web-, Datenbank- oder Control-Plane-Pods auf denselben Nodes geschedult.

Keine Secrets in der Sandbox. Der Agent hält weder das Git-Token noch den LLM-Key des Kunden. Die vertrauenswürdige Plane macht git clone und git push serverseitig, die Sandbox bekommt eine Arbeitskopie ohne Credentials und liefert ein Diff zurück. Der LLM-Key wird von einem Egress-Proxy mit einem per-Run-Token injiziert. Der echte Key betritt die Sandbox nie. Der einzige ausgehende Pfad der Sandbox führt durch das MCP-Gateway (Model Context Protocol) plus LLM-Proxy. Der Agent ist damit reine „Rechenleistung mit Allowlist".

Architektur-Entscheidungen und Learnings

Eine Abstraktion, vier Forge-Provider. Statt für jeden Forge einen eigenen Codepfad zu bauen, gibt es genau ein IForgeClient-Interface, hinter dem die Provider-Spezifika sauber liegen. Webhooks, MR-Erstellung, Inline-Comments, OAuth-Flows. Alles läuft durch dieselbe Tür. Das macht Multi-Forge nicht nur möglich, sondern wartbar.

Jede Rolle ihr Modell. Multi-Agent-Workflows funktionieren nur, wenn die Rollen klar getrennt sind. Und jede ihr passendes Modell bekommt. Der Planner darf länger denken und teurer sein, der Coder muss schnell und konsistent liefern, der Reviewer braucht solides Tooling-Wissen. Ein-Modell-für-alles ist immer ein Kompromiss, explizite Rollen-Modelle sind ein Hebel.

BYOK statt Token-Markup. LLM-Preise sind volatil, Anbieter konkurrieren hart, und Kunden haben starke bestehende Präferenzen. Marge auf Tokens zu schlagen macht die Kosten für alle intransparenter. Mit Bring Your Own Key zahlt der Kunde seinen LLM-Anbieter direkt, wir verdienen am Produkt, nicht an dessen Compute. Das richtet die Anreize aus: wir sind motiviert, den Agent effizienter zu machen, nicht teurer.

Konfiguration auf drei Ebenen. Fragon Forge löst Konfiguration in einer klaren Hierarchie auf: Global (Plattform-Defaults), pro Repository (Dashboard-Overrides), und im Repository (eine .fragonforge.yml überschreibt alles). Das ermöglicht Teams, ihre Einstellungen selbst zu verwalten, ohne Admin-Zugriff auf das Dashboard zu brauchen.

Ergebnisse

Fragon Forge unterstützt heute vier Forge-Provider (GitHub, GitLab, Gitea/Forgejo, Bitbucket Cloud), integriert über zwölf Analyse-Tools mit aggregiertem Dashboard und liefert Merge Requests in unter fünf Minuten. Multi-Agent-Workflows, Repo-aware RAG, Persistent Lessons, branch-aware Quality Gates und VM-Grade Sandbox-Isolation gehören zur Standardausstattung.

Der commercial Launch ist für Q3 bis Q4 2026 geplant. Der Free Tier startet bei €0/Monat (1 Repo, 100 Runs/Monat, BYOK ab Run 1, keine Kreditkarte), Solo bei €29/Monat, Team bei €99/Monat. Inkl. BYOK, ohne Token-Markup, EU-gehostet auf self-managed Kubernetes bei Hetzner Bare-Metal in Deutschland.

Takeaways für Ihre Projekte

KI-Agenten funktionieren am besten asynchron. Ein „Fire-and-Forget"-Ansatz mit klarem Kontext liefert bessere und schnellere Ergebnisse als interaktive Chatbots, die Rückfragen stellen.

Verantwortung trennen, auch bei Agenten. Ein Agent für alles wird mit steigender Komplexität schlechter, nicht besser. Klare Rollen mit dedizierten Modellen skalieren besser als ein universeller Allrounder.

Die Isolation, die intuitiv ist, ist oft nicht die, die zählt. Physische Trennung beruhigt das Bauchgefühl, aber sie löst nur ein Risiko. Wer fremden Code ausführt, braucht Isolation in mindestens drei Schichten: Daten, Ausführung und Capabilities. Und sollte sich nicht darauf verlassen, dass eine davon die anderen mitlöst.

Konfigurierbarkeit auf mehreren Ebenen (global, per repo, im repo) skaliert besser als ein zentralisiertes Settings-Panel, weil Teams Ownership über ihre Konfiguration behalten.

Warum wir das hier teilen

Fragon Forge ist das interne Produkt, an dem wir lernen, wie wir komplexe SaaS-Architekturen bauen. Multi-Tenant-Isolation, Sandbox-Ausführung und das ehrliche Umgehen mit Sackgassen sind für uns keine Featureliste, sondern Arbeitsweise. Das gleiche Denken bringen wir in Mandantenprojekte mit.

Fragon Forge ist ein Produkt von Fragon Studios e.U. Launch: Q3 bis Q4 2026. Weitere Informationen auf app.fragonforge.com.