Ein Workflow vom Repository bis zum Cluster

Vom Commit zur laufenden Workload soll ein Weg genügen. Nicht eine Kette aus CI, Registry-Konto, Cluster-Zugang und Rollback, die jedes Team neu zusammenklebt. Repository, Ziel-Cluster und Rechte gehören in denselben Account.

GitHub verbinden, Cluster wählen

Du hast einen gemanagten Cluster im Projekt. Dann verbindest du GitHub in der Loopback-Oberfläche. Das Team legt ein Bundle an, wählt den Ziel-Cluster und konfiguriert den Deployment-Weg. Environments zeigen auf den Cluster. Deploy, Rollback und Undeploy steuerst du in Loopback. Ein Bundle kannst du jederzeit anpassen, es ist der Workflow deines Teams.

Bundles sind in der Beta und für alle nutzbar. Du startest direkt mit deinem GitHub-Repository.

Images in derselben Organisation

Bundles legen Images automatisch in der Registry der Organisation ab. Die Registry gilt organisationsweit, für Images und Helm Charts, mit Loopback-RBAC und Robot Accounts, betrieben in Deutschland. Der Cluster zieht seine Images aus derselben Registry. Wer deployen darf, legst du über Gruppen und feingranulare Rollen fest, mit SSO, OTP, Passkeys und API Tokens.

Ein durchgehender Weg: Repository, Build, Image, Cluster, Rollback. In einem Account.

Der Cluster bleibt Standard-Kubernetes

Der Ziel-Cluster ist dasselbe Kubernetes-Produkt wie in Produktion: HA Control Plane, privates Netz, Scaling Groups und One-click Upgrades. Die Loopback GmbH betreibt die Plattform, die Plattformdaten bleiben in Deutschland. Deine Workloads laufen am Standort, den du wählst.

Der nächste Schritt

Lege ein Bundle an, verbinde GitHub und wähle den Ziel-Cluster. Deine Images landen in der Registry der Organisation, der Cluster zieht sie aus demselben Kontext.