GitOps Director läuft als echtes Backstage-Plugin — kein iFrame, kein separater Auth-Flow, keine zweite Oberfläche. Installation per Package-Manager, Integration in den Backstage-Katalog, fertig.
GitOps Director verwendet die offiziellen Backstage Plugin-APIs — kein Monkey-Patching, keine undokumentierten Hooks. Das Plugin verhält sich wie jedes andere Backstage-Plugin aus dem Core-Ökosystem.
Im Backstage-App-Verzeichnis:
Plugin in packages/app/src/App.tsx einbinden — Standard-Backstage-Pattern, keine Sonderlösung:
GitOps Director liest den Backstage Software-Catalog für Service-Discovery. Bestehende catalog-info.yaml-Dateien werden für die Zuordnung von Ressourcen zu Services genutzt. Keine separate Service-Registry nötig.
Bestehende Backstage Software Templates können mit GitOps-Director-Actions angereichert werden: gitops:provision, gitops:destroy, gitops:update. Das Template orchestriert den vollständigen IaC-Flow.
Das Dashboard erscheint direkt in der Backstage-Navigation — gleiche Sidebar, gleiche Authentifizierung, kein Login-Wechsel.
GitOps Director integriert sich in alle relevanten Backstage-APIs und -Frameworks — kein Workaround, keine proprietären Hooks.
spec.owner) steuerbarAndere IaC-Self-Service-Lösungen laufen als eigene Webapplikation — mit eigenem Auth, eigenem Benutzermanagement, eigenen Updates. GitOps Director ist ein Plugin: wenn Backstage läuft, läuft GitOps Director. Kein separater Service, kein separates Monitoring.
Developers kennen Backstage bereits. GitOps Director erscheint in der Sidebar des vertrauten Portals — kein neues Tool-Login, kein Bookmark zu einem weiteren internen System. Service-Catalog und Infrastruktur-Self-Service sind direkt nebeneinander erreichbar.
Wir zeigen die Installation und die Katalog-Integration in einer 30-minütigen Session — mit Ihrem eigenen Backstage-Setup als Ausgangspunkt.