GitOps Director
Produkt-Übersicht Auto-UI Generator Git-nativer Workflow Backstage-Integration RBAC & OPA Governance Audit-Trail by Design On-Prem & Air-Gap
Platform Engineers Developers CTOs & Architekten
Services
Über uns Karriere
Preise
Demo buchen →
Produkt-Übersicht
GitOps

Git-nativer Workflow — kein Schritt außerhalb des Repos.

Jede Provisionierung, jede Änderung, jede Löschung erzeugt automatisch einen Feature-Branch und einen Merge Request — mit vollständigem Diff, Plan-Output und Reviewer-Links. Git ist Ihre Single Source of Truth.

← Alle Features
4Git-Plattformen unterstützt
100%der Aktionen im Git-Log
0Aktionen ohne Branch
WIE ES FUNKTIONIERT

Vom Formular-Submit zum Merge Request in Sekunden.

Andere Self-Service-Portale schreiben direkt in den Main-Branch oder gegen eine eigene Datenbank. GitOps Director tut weder das eine noch das andere — jede Aktion landet als reviewbarer MR in Ihrem Repo.

1

Formular-Submit löst Branch-Erstellung aus

Sobald ein Developer das Provisionierungs-Formular absendet, erzeugt GitOps Director einen Feature-Branch gegen Ihr Haupt-Repository. Branch-Name nach konfigurierbarer Konvention, z.B. infra/dev-jsmith-rds-mysql-1722858920.

2

IaC-Dateien werden committet

Die vorausgefüllten .tfvars-, values.yaml- oder Crossplane-Manifest-Dateien werden mit dem Autor-Namen und Timestamp committet. Commit-Message wird automatisch generiert.

3

MR mit Plan-Output wird eröffnet

Der Merge Request enthält den vollständigen Infrastruktur-Diff, den Terraform Plan-Output (oder Helm Dry-Run), und konfigurierbare Reviewer. MR-Template aus Ihrem Repo wird respektiert.

4

Auto-Merge nach definierten Conditions

Konfigurierbar: MR mergt automatisch nach n Approvals und grüner Pipeline, oder bei bestimmten Ressource-Typen direkt ohne Review. Für privilegierte Environments (Prod) kann ein Force-Review erzwungen werden.

BEISPIEL MERGE REQUEST
!247 · infra: provision rds-mysql for payments-svc
Branch: infra/dev-jsmith-rds-mysql-1722858920 → main
Erstellt von: Jonas Schmidt via GitOps Director · vor 2 min
Reviewer: @sre-team, @sec-team
+ resource "aws_db_instance" "payments_mysql" { + identifier = "payments-mysql-prod" + engine = "mysql" + engine_version = "8.0.35" + instance_class = "db.t3.medium" + allocated_storage = 100 + db_subnet_group_name = module.vpc.db_subnet_group + }
terraform plan: +1 resource 2 Approvals required

Jedes Feld — Instanztyp, Storage, Subnet — kommt direkt aus dem Formular. Der Reviewer sieht genau, was deployed wird, bevor er approvet.

DEPENDENCY-GRAPH

Jede provisionierte Resource — vollständig sichtbar.

GitOps Director zeigt alle Ressourcen mit ihren Git-Branches, MR-Status und Abhängigkeiten im Überblick. Wer hat was wann deployed — direkt sichtbar, ohne Git-Log zu lesen.

GitOps Director Dependency-Graph — Alle Ressourcen mit MR-Status
Dependency-Graph: Ressourcen, Branches, Approval-Status in einer Ansicht
TECHNISCHE SPEZIFIKATION

Unterstützte Git-Plattformen und Branch-Konfiguration.

Git-Plattform-Support

GitLabGitLab CE/EE ab v14 — MR-API, Pipeline-Integration, Protected-Branches
GitHubGitHub.com und GitHub Enterprise Server — PR-API, Status-Checks, Branch-Protection
GiteaGitea ab v1.18 — vollständige On-Prem-Integration ohne Cloud-Dependency
BitbucketBitbucket Server / Data Center — PR-Workflows und Review-Integration
Azure DevOpsAzure Repos (Git) — Pull Request API, Branch Policies

Branch & MR-Konfiguration

Branch-PatternKonfigurierbar per Template: infra/{env}-{user}-{resource}-{ts}, beliebige Token
Target-BranchKonfigurierbar pro Template: main, env/staging, releases/q4
Auto-MergeBedingungen: min. Approvals, Pipeline-Status, Zeit-Fenster, Label-basiert
MR-InhaltDiff, Plan-Output, Metadaten (User, Timestamp, Resource-ID), Custom-Template
Protected BranchesGitOps Director respektiert bestehende Branch-Protection-Rules vollständig
FÜR WEN ES RELEVANT IST

Git als gemeinsame Sprache von Plattform und Dev.

Platform Engineers

Kein Shadow-State außerhalb von Git

Andere Tools halten Resource-State in proprietären Datenbanken. Bei GitOps Director ist das Git-Repository die einzige Wahrheit. Kein Abgleich-Problem zwischen Tool-DB und tatsächlicher Infrastruktur. Kein Vendor-Lock-in durch proprietäre State-Formate.

Bestehendes GitOps-Tooling (ArgoCD, Flux) bleibt
Branch-Protection-Rules bleiben wirksam
Kein direkter Main-Branch-Push von Usern möglich
Developers

Git-Workflow ohne Git-Kommandozeile

Der Developer muss keinen Branch anlegen, keinen Commit schreiben, kein MR öffnen. Das alles passiert automatisch nach dem Formular-Submit. Das Ergebnis — ein reviewbarer MR — ist aber genau das, was das Platform-Team erwartet. Kein Medienbruch.

Status-Tracking über den MR-Link
Benachrichtigung bei Approval oder Ablehnung
Änderungs-Requests als MR-Kommentare
NÄCHSTER SCHRITT

Sehen Sie Ihren ersten automatischen MR live.

Wir demonstrieren den vollständigen Flow — Formular-Submit bis zum offenen MR in Ihrem Repository — in unter 5 Minuten.

Bereit für Self-Service Infrastruktur?
15-minütige Demo · Kein Setup · Direkt mit einem Solution Engineer
Demo buchen →