Fragon Forge ist unser eigenes Produkt: ein KI-Agent, der aus einer Aufgabenbeschreibung einen fertigen Änderungsvorschlag für den Code liefert, in der Fachsprache eine Merge Request. Wir setzen es in unseren eigenen Projekten ein, der kommerzielle Start ist für das erste Quartal 2027 geplant. Für Sie als Auftraggeber ist dieser Text vor allem ein Beleg dafür, wie wir Software bauen, die viele Kunden gleichzeitig und sicher nutzen.
| Projekt | Eigenentwicklung, Fragon Studios |
| Branche | Werkzeuge für Softwareentwickler |
| Technologien | .NET 10, React 19, TypeScript, PostgreSQL, Qdrant, Kubernetes, MCP, OpenCode |
| Zeitraum | seit 2025, laufend |
| Stand | Im eigenen Einsatz, kommerzieller Start im ersten Quartal 2027 |
| Ergebnis | Von der Aufgabe zur Merge Request ohne Handarbeit, für vier Git-Plattformen |
Softwareentwicklung besteht zu einem großen Teil aus wiederkehrenden Arbeiten: Grundgerüste schreiben, Bibliotheken aktualisieren, Code prüfen, Sicherheitslücken suchen. Als kleines Softwarestudio haben wir uns gefragt, ob ein KI-Agent diese Arbeiten selbstständig erledigen kann, und zwar im gewohnten Ablauf mit Git.
Die verfügbaren Lösungen (GitHub Copilot, CodeRabbit, Cursor und andere) waren an GitHub gebunden, deckten nur einen Teil ab oder verlangten einen Ablauf, der mit der eigenen Git-Plattform wenig zu tun hatte. Für Teams mit GitLab, Gitea oder Bitbucket und strengen Vorgaben nach DSGVO passte keine davon.
Wir haben Fragon Forge zuerst als Werkzeug für unsere eigenen Repositories gebaut. Nach einigen Monaten im eigenen Einsatz war klar, dass vielen anderen Teams dasselbe fehlt. So wurde aus dem internen Werkzeug ein Produkt.
Aus einem internen Werkzeug ein Produkt zu machen heißt, mehrere Aufgaben gleichzeitig zu lösen.
GitHub, GitLab (CE und EE), Gitea/Forgejo und Bitbucket Cloud haben eigene Schnittstellen, eigene Formate für Benachrichtigungen (Webhooks) und eigene Anmeldeverfahren. Die gemeinsame Schicht darüber muss sauber sein, sonst wächst der Aufwand mit jeder Plattform.
Ein Entwickler beschreibt eine Aufgabe (Issue), die KI liefert eine Merge Request und prüft sie anschließend selbst auf Sicherheitsprobleme, verwundbare Bibliotheken und Stil.
Ein Agent, der im Auftrag eines Kunden Code schreibt, führt auch dessen Code aus: Tests, Builds, Prüfwerkzeuge. In einem kostenlosen Tarif heißt das, beliebigen Code von beliebigen Leuten laufen zu lassen, viele Male am Tag. Ohne harte Abschottung ist das ein Sicherheitsrisiko.
Betrieb in der EU, auf Wunsch mit eigenem Schlüssel für das Sprachmodell (BYOK, Bring Your Own Key), kein Training mit Kundencode. Wer Fragon Forge nutzt, soll wissen, wo seine Daten liegen und wer sie sieht.
Fragon Forge wird per Webhook mit Ihrer Git-Plattform verbunden und hat vier Kernfunktionen.
Ein Entwickler legt ein Issue an und setzt das Label ai-task (oder ruft den Agenten mit @fragonforge im Kommentar). Fragon Forge empfängt den Webhook und klont das Repository, ein KI-Agent liest die Aufgabe und schreibt den Code. Danach öffnet Fragon Forge eine Merge Request im Entwurfsstatus samt eigener Prüfung. Der Entwickler kontrolliert und übernimmt sie.
Für Ihr Projekt heißt das: Entscheidend war, den Agenten nicht als Chat zu bauen. Er bekommt einmal den vollständigen Zusammenhang und liefert ein Ergebnis, statt Rückfragen zu stellen. Der Entwickler muss nicht warten und kann inzwischen etwas anderes tun.
Bei jeder Merge Request läuft eine Analyse mit: Semgrep und Trivy für Sicherheit und Container-Schwachstellen, Gitleaks für versehentlich eingecheckte Zugangsdaten, Checkov und trivy config für Infrastruktur-Code (Terraform, Kubernetes, Helm, Bicep), dazu ESLint, RuboCop, PHPStan, Ruff und Clippy für einzelne Sprachen sowie Lizard und jscpd für Komplexität und doppelten Code.
Die Ergebnisse landen in einem Dashboard mit Note von A bis F, Aufteilung nach Schwere und Verlauf über die Zeit. Nur neue Funde blockieren die Merge Request, bestehende Altlasten halten die Arbeit nicht auf. Findet der Agent etwas, das er selbst beheben kann, löst das Label autofix-ready einen Korrekturlauf aus.
Die Werkzeuge laufen im selben abgeschotteten Lauf wie der Coding Agent und nicht als eigene CI-Pipeline. Dadurch liegen die Ergebnisse strukturiert in der Datenbank, und das Dashboard kann Verläufe über alle Branches und Repositories zeigen.
Ein einzelner Agent funktioniert bis zu einer gewissen Größe der Aufgabe, danach steht er sich selbst im Weg. Fragon Forge trennt deshalb Planung, Umsetzung und Prüfung, jeweils mit eigenem Sprachmodell. Für die Planung eignen sich stärkere Modelle (zum Beispiel Claude Opus), für die Umsetzung schnellere (zum Beispiel Claude Sonnet).
Im Modus mit Spezifikation wird die Kette ausdrücklich: Aus dem Issue wird zuerst eine Spezifikation, dann Tests, dann Code, dazwischen gibt ein Mensch frei. Für ganze Projekte gibt es eine ausführliche Planung mit Erkundung, Architektur, Zerlegung in Teilaufgaben und einer abschließenden Bewertung.
Der Agent liest Ihr Repository mit tree-sitter ein und legt es in einem Vektorspeicher (Qdrant) ab. So findet er passenden Code im gesamten Projekt und nicht nur in der Datei, die er gerade bearbeitet. Was er aus früheren Aufgaben gelernt hat, wird gespeichert, allgemein und je Repository. Kommentare an einer Merge Request von Fragon Forge starten den Agenten mit dem vollen Zusammenhang erneut, damit Rückmeldungen nicht verloren gehen.
Die erste Fassung sah anders aus. Jeder Kunde bekam einen eigenen Fragon-Forge-Container mit eigener Datenbank und eigenem Speicher. Das wirkte naheliegend, denn räumliche Trennung ist das einfachste Bild von Abschottung: keine geteilten Zeilen, keine vergessenen WHERE-Klauseln, keine geteilte Warteschlange.
Sauber war das auch. Es wächst aber nicht mit.
Drei Dinge hatten wir unterschätzt.
Ein Container je Kunde heißt ein Container je Konto mit festem Grundverbrauch, ob das Konto aktiv ist oder nicht. In einem kostenlosen Tarif ohne Kreditkarte werden daraus Hostingkosten, die den Tarif unmöglich machen.
Hunderte Container heißen: jedes Update, jede Überwachung, jede Sicherung und jede Datenbankänderung hundertfach. Dazu kommen ein Reverse-Proxy mit automatischer Einrichtung, die Anmeldung zwischen Steuerung und Kundencontainer und unterschiedliche Versionen je Container. Was zentral einfach ist, wird zur Abstimmungsarbeit.
Getrennte Daten je Container lösen die Frage, ob ein anderes Konto Ihre Zeilen sieht. Das eigentliche Risiko bei einem Coding Agent liegt aber darin, dass er fremden Code ausführt. Dagegen hilft ein Container je Kunde nicht, denn dieser Container führt den Code des Kunden ohnehin aus. Die Frage der Abschottung liegt eine Ebene tiefer als die Frage der Mandanten.
Den Umbau haben wir schrittweise über mehrere Versionen gemacht und nicht als Neubau. Das war langsamer, aber jeder Zwischenstand blieb lauffähig.
Heute gibt es eine gemeinsame PostgreSQL-Datenbank mit Filtern je Mandant (Trennung der Daten), einen kurzlebigen Kubernetes-Job in einer eigenen virtuellen Maschine je Lauf (Trennung der Ausführung) und ein MCP-Gateway als einzigen Weg aus der Sandbox (Trennung der Berechtigungen). Das sind drei Ebenen für drei verschiedene Risiken, und keine davon hätte ein Container je Kunde gelöst.
Viele Konten teilen sich bei Fragon Forge eine Anwendung und eine Datenbank. Daten und Läufe sind durch den Aufbau getrennt, nicht durch Vertrauen.
Eine PostgreSQL-Datenbank, ein Schema, jede Zeile eines Mandanten trägt dessen Kennung. Die Trennung wird in der Zugriffsschicht erzwungen (EF Core Global Query Filters), bei jeder Anfrage und bei jedem Hintergrundjob, nie über einzelne WHERE-Klauseln, die jemand vergessen könnte. Ein Test mit zwei Mandanten prüft jeden Endpunkt, jeden Hintergrundpfad und jede Suchanfrage auf Lecks. Ohne bestandenen Test geht keine Version hinaus.
Den Agenten auf ein fremdes Repository loszulassen heißt, beliebigen Code auszuführen. Jeder Lauf ist ein einmaliger Kubernetes-Job: ohne Root-Rechte, mit schreibgeschütztem Dateisystem, mit Grenzen für Rechenzeit, Speicher, Prozesse, Platte und Dauer und mit gesperrtem Netzwerk nach außen. Jeder Lauf bekommt in jedem Tarif eine eigene virtuelle Maschine (Kata Containers). Die Maschinen für Agentenläufe stehen getrennt von denen für Web, Datenbank und Steuerung.
Der Agent kennt weder den Git-Zugang noch den Schlüssel für das Sprachmodell. Die vertrauenswürdige Seite führt git clone und git push aus, die Sandbox bekommt eine Arbeitskopie ohne Zugangsdaten und gibt die Änderungen zurück. Den Schlüssel für das Sprachmodell setzt ein Proxy für jeden Lauf einzeln ein. Der einzige Weg aus der Sandbox führt durch das MCP-Gateway (Model Context Protocol) und diesen Proxy.
Statt für jede Plattform einen eigenen Weg durch den Code zu bauen, gibt es eine einzige Schnittstelle (IForgeClient), hinter der die Besonderheiten liegen: Webhooks, Merge Requests, Kommentare an Codezeilen, Anmeldung. Das hält vier Anbindungen wartbar.
Mehrere Agenten funktionieren nur mit klar getrennten Rollen. Die Planung darf länger dauern und mehr kosten, die Umsetzung muss schnell und gleichmäßig liefern, die Prüfung braucht Wissen über die Werkzeuge. Ein Modell für alles ist immer ein Kompromiss.
Die Preise für Sprachmodelle schwanken, und viele Kunden haben schon einen Vertrag mit einem Anbieter. Deshalb kann jeder seinen eigenen Schlüssel hinterlegen, dann rechnet der Anbieter direkt mit dem Kunden ab. Wer keinen eigenen Vertrag möchte, nutzt das KI-Budget, das in den bezahlten Tarifen enthalten ist.
Einstellungen gelten in einer festen Reihenfolge: für die ganze Plattform, je Repository im Dashboard und im Repository selbst (eine Datei .fragonforge.yml überschreibt alles). Teams verwalten ihre Einstellungen damit selbst und brauchen dafür keinen Adminzugang.
Fragon Forge unterstützt vier Git-Plattformen (GitHub, GitLab, Gitea/Forgejo, Bitbucket Cloud) und bindet mehr als zehn Analysewerkzeuge in ein gemeinsames Dashboard ein. Getrennte Rollen für mehrere Agenten, die Suche im gesamten Repository, gespeicherte Lektionen und eine eigene virtuelle Maschine je Lauf gehören zum Umfang. Wir nutzen es in unseren eigenen Repositories.
Der kommerzielle Start ist für das erste Quartal 2027 geplant. Die Preise laut fragonforge.com, Stand November 2026:
| Tarif | Preis | Umfang |
|---|---|---|
| Free | 0 € | 1 Repository, 1 Nutzer, 100 Läufe im Monat, mit eigenem Schlüssel |
| Solo | 29 € im Monat | 3 Repositories, 1 Nutzer, 300 Läufe im Monat, 7,50 € KI-Budget |
| Team | 99 € im Monat | 10 Repositories, 10 Nutzer, 1.500 Läufe im Monat, 25 € KI-Budget |
| Business | 299 € im Monat | 30 Repositories, 30 Nutzer, 5.000 Läufe im Monat, 75 € KI-Budget |
Betrieben wird Fragon Forge in der EU, auf selbst verwaltetem Kubernetes bei Hetzner in Deutschland.
Ein Auftrag mit vollständigem Zusammenhang liefert bessere und schnellere Ergebnisse als ein Chat, der nachfragt.
Ein Agent für alles wird mit wachsender Aufgabe schlechter. Klare Rollen mit eigenem Modell halten länger durch.
Räumliche Trennung beruhigt, löst aber nur ein Risiko. Wer fremden Code ausführt, braucht Trennung auf mindestens drei Ebenen: Daten, Ausführung und Berechtigungen.
Einstellungen für die Plattform, je Repository und im Repository selbst wachsen besser mit als eine zentrale Einstellungsseite, weil Teams die Verantwortung für ihre Einstellungen behalten.
An Fragon Forge lernen wir, wie man Software für viele Kunden baut: Daten trennen, fremden Code abschotten und einen falschen Weg rechtzeitig verlassen. Dieselbe Arbeitsweise bringen wir in Kundenprojekte mit.
Fragon Forge ist ein KI-Agent, der aus einer Aufgabenbeschreibung einen fertigen Änderungsvorschlag für den Code liefert (Merge Request) und ihn anschließend selbst prüft. Es ist ein Produkt von Fragon Studios aus Linz. Wir setzen es in unseren eigenen Projekten ein, der kommerzielle Start ist für das erste Quartal 2027 geplant.
GitHub, GitLab (CE und EE), Gitea/Forgejo und Bitbucket Cloud. Die Anbindung läuft über einen Webhook, der Ablauf ist auf allen vier Plattformen derselbe.
Es gibt vier Tarife: Free für 0 €, Solo für 29 €, Team für 99 € und Business für 299 € im Monat. Das sind die Preise laut fragonforge.com mit Stand November 2026. Der kostenlose Tarif arbeitet mit einem eigenen Schlüssel für das Sprachmodell, die bezahlten Tarife enthalten ein KI-Budget.
In der EU, auf selbst verwaltetem Kubernetes bei Hetzner in Deutschland. Mit Kundencode wird kein Modell trainiert. Wer möchte, hinterlegt einen eigenen Schlüssel für das Sprachmodell, dann rechnet der Anbieter direkt mit dem Kunden ab.
Jeder Lauf ist ein einmaliger Kubernetes-Job in einer eigenen virtuellen Maschine (Kata Containers), ohne Root-Rechte, mit schreibgeschütztem Dateisystem und gesperrtem Netzwerk nach außen. Der Agent kennt weder den Git-Zugang noch den Schlüssel für das Sprachmodell. Der einzige Weg aus der Sandbox führt über ein Gateway und einen Proxy.
Fragon Forge ist ein Produkt von Fragon Studios e.U. Kommerzieller Start: erstes Quartal 2027. Mehr auf fragonforge.com.