GitLab Artifact Central: alle Artefakte unter einem Dach

Jeder Software-Build setzt sich aus Open-Source-Paketen, Basis-Images und Bibliotheken zusammen, darauf kommt der eigene Code. Fehlt eine dieser Komponenten oder hat sie sich unbemerkt verändert, schlägt der Build fehl. Wenn KI-Agenten kontinuierlich Builds anstoßen, häufen sich solche Fehler – und kein Team kann sie noch einzeln als manuelle Ausnahme behandeln.

Verschärft wird das durch Registrys, die Projekt für Projekt entstehen: Aufbewahrungsregeln, Speicherlimits und Veröffentlichungsrechte liegen jeweils getrennt im einzelnen Projekt. Solange jemand jede Registry von Hand einrichtet, funktioniert dieses Modell. Laufen dagegen Agenten dauerhaft über Hunderte von Projekten hinweg, stößt es an seine Grenzen.

Auf der GitLab Transcend haben wir heute GitLab Artifact Central vorgestellt: eine Registry auf Organisationsebene, die Hunderte von Registrys auf Projektebene ersetzt. Jeder Abruf und jede Veröffentlichung – ob durch Menschen oder Agenten – läuft damit über denselben kontrollierten Zugang. Plattform-Teams stellen so sicher, dass Software von Anfang an aus den richtigen Komponenten entsteht.

Im Folgenden erläutern wir, warum wir Artifact Central entwickelt haben und wie es deine Teams unterstützt.

Richtlinien einmal festlegen, überall durchsetzen

Bisher liegen Aufbewahrungsregeln, Speicherlimits und Veröffentlichungsrechte in GitLab in der kostenlosen Paket- und Container-Registry des jeweiligen Projekts und werden dort einzeln konfiguriert. GitLab Artifact Central verlagert diese Aufgabe eine Ebene nach oben: Teams legen Aufbewahrungsregeln, Kontingente und Zugriffsrichtlinien einmal auf Organisationsebene fest, statt sie in jedem darunterliegenden Projekt neu anzulegen.

Jedes Repository ist standardmäßig geschlossen. Die Mitgliedschaft in der Organisation ist Voraussetzung, nicht Freigabe: Sie allein öffnet kein einziges Repository, solange keine Rolle den Zugriff gewährt. Dafür gibt es vier eigene Rollen für Artefakte: Admin, Manager, Contributor und Viewer. Sie sind von den bestehenden Projektrollen in GitLab getrennt – wer Zugriff auf ein Repository erhält, bekommt damit an keiner anderen Stelle zusätzliche Rechte.

Eine URL für Veröffentlichung, Proxy oder beides

Statt auf einer internen Wiki-Seite nachzuschlagen, was wo liegt, verwenden Entwickler(innen) eine einzige URL für alles. Dafür bietet GitLab Artifact Central drei Repository-Typen:

• Hosted: Private Pakete und Images, die deine Teams selbst erstellen und veröffentlichen.
• Remote: Ein Proxy vor einer externen Quelle wie Docker Hub oder Maven Central. Die Verbindung wird getestet, bevor etwas davon abhängt.
• Virtual: Ein gemeinsamer Endpunkt für Hosted- und Remote-Repositorys. GitLab prüft zuerst das Hosted-Repository und greift dann auf die externe Quelle zurück. Der erste externe Abruf wird zwischengespeichert; alle weiteren Abrufe kommen direkt aus GitLab, ohne erneuten Weg ins Internet.

Virtual-Repositorys sind vor allem für Teams relevant, die GitLab mit anderen Lösungen für das Artefaktmanagement vergleichen. Sie bieten Entwickler(inne)n den gewohnten einzelnen Endpunkt, ohne dass sie wissen müssen, wo ein Artefakt liegt. Ob intern erstellt oder aus einer externen Registry bezogen: Angefordert wird es immer auf dieselbe Weise. In der Beta unterstützt Artifact Central Maven, npm, Docker und OCI; weitere Formate folgen.

Herkunft automatisch nachvollziehen

Ein Punkt lässt sich außerhalb von GitLab nur mit Aufwand nachbilden: Jedes Artefakt, das über GitLab Artifact Central veröffentlicht wird, bringt automatisch seine Build-Provenienz mit – welche Pipeline es erstellt hat, aus welchem Branch und Commit es stammt und wer den Job ausgelöst hat. Da dieselbe Plattform den Build ausgeführt hat, liegen der Registry diese Informationen bereits vor.

Bei der Authentifizierung gilt dasselbe Prinzip. Veröffentlichen und Abrufen laufen über CI_JOB_TOKEN, die Identität, die deine Pipelines ohnehin haben – für Menschen wie für Agenten. Ein Agent, der über CI-Pipelines veröffentlicht oder abruft, nutzt genau dieses Job-Token und kein nachträglich ergänztes Servicekonto mit eigenen Berechtigungen, die separat gepflegt werden müssen. Bei einer eigenständigen Registry bedeutet die Rückverfolgung eines Artefakts, IDs aus CI-System und Registry separat abzugleichen – per Skript, das jemand verantworten und pflegen muss. Bei Artifact Central sind Pipeline, Branch, Commit und Job direkt am Artefakt hinterlegt.

Auf einen Blick: Was haben wir veröffentlicht?

Artifact Central befindet sich auf derselben Plattform wie Code, Merge Requests und Pipelines. Artefakte, die aus CI veröffentlicht werden, enthalten deshalb ihre Build-Provenienz: die Pipeline, die sie erstellt hat, den Commit und die Person, die sie veröffentlicht hat.

Als Nächstes wollen wir diese Informationen über GitLab Orbit organisationsweit verknüpfen. Die Frage „Welche unserer laufenden Services sind von dieser Sicherheitslücke betroffen?“ hat dann eine einzige Antwort – statt einer manuellen Suche über vier oder fünf Tools hinweg.

Artifact Central mit Dependency Firewall kombinieren

GitLab Dependency Firewall ist ein separates GitLab-Produkt, das sich derzeit in der Early-Access-Phase für Premium- und Ultimate-Kund(inn)en befindet. Es funktioniert direkt mit Artifact Central zusammen. Mit Dependency Firewall lassen sich riskante Pakete stoppen, bevor sie in einen Build gelangen. Die Prüfung wird mit der glab-CLI in die jeweilige Pipeline eingebunden; die Abdeckung erfolgt also Pipeline für Pipeline, unabhängig vom Paketmanager, den deine Teams nutzen. Als Nächstes planen wir eine engere Integration beider Funktionen: Dann blockiert eine einzige Richtlinie für die gesamte Organisation riskante Pakete nach Sicherheitslücke, Lizenz oder Paketalter, sobald sie abgerufen werden.

Eine Registry, zwei Perspektiven

So sieht das in der Praxis aus – aus Sicht der Entwicklung, die Code ausliefert, und aus Sicht des Plattform-Teams, das dafür sorgt, dass alles zusammenpasst.

Entwicklung: Veröffentlichen aus CI. Deine Pipeline veröffentlicht ein Maven-Artefakt mit dem Job-Token, das sie bereits hat – ohne neue Secrets, die verwaltet werden müssen. Braucht dieselbe Person ein internes Paket und zusätzlich eines aus Maven Central, verweist sie auf eine einzige Virtual-Repository-URL. Wo welches Paket tatsächlich liegt, klärt GitLab Artifact Central.

Plattform-Team: Richtlinien einmal festlegen. Statt Regeln in Hunderten einzelner Projekte zu konfigurieren, legen Admins Speicherkontingente und Zugriffsregeln einmalig auf Organisationsebene fest – und jedes darunterliegende Repository übernimmt sie. Fragt jemand, wie viel das Unternehmen wo speichert, liefert ein einziges Dashboard die Antwort.

Artefakte migrieren

Die meisten Unternehmen fangen nicht bei null an, und ein harter Wechsel von einer bestehenden Registry ist selten realistisch. Mit GitLab Artifact Central bindest du bestehende Repositorys als Remote-Repositorys hinter einem Virtual-Repository ein. Entwickler(innen) nutzen eine einzige URL, und Artefakte werden erst dann übernommen, wenn ein Build sie tatsächlich anfordert. Massenkopien, Migrationsfenster am Wochenende oder das Verschieben von Petabytes an Daten durch das Netzwerk entfallen.

Die bisherige Registry bleibt das führende System. Wenn du so weit bist, wandelst du das Remote-Repository in ein Hosted-Repository in Artifact Central um. So erfolgt die Migration schrittweise und mit geringerem Risiko.

Artifact Central kostenlos in der Beta testen

GitLab Artifact Central ist ab heute als Beta für GitLab.com verfügbar; die Verfügbarkeit für GitLab Self-Managed ist noch für Oktober geplant. Während der Beta fallen keine Kosten an, und es muss nichts erworben werden. Wir werten die Nutzung aus, um das Preismodell bis zur allgemeinen Verfügbarkeit festzulegen, und informieren dann über die Details.

Artifact Central gemeinsam weiterentwickeln

Ohne unsere Designpartner wäre Artifact Central nicht da, wo es heute steht. Sie setzen es seit mehreren Wochen in realen Workflows ein, und ihr Feedback ist in den heutigen Funktionsumfang eingeflossen. Dein Feedback fließt in die nächsten Schritte ein.

Für die Teilnahme an der Beta ist keine Einladung erforderlich: Registriere dich auf unserer Website, dann meldet sich ein Mitglied unseres Teams, um die Funktion für dein Konto freizuschalten. Auch ohne GitLab-Konto kannst du dich für die Beta anmelden; wir melden uns dann bei dir.

Wir sind gespannt, was du damit umsetzt.

Sieh dir die Aufzeichnung unseres Transcend-Events an – mit Demos der neuen Plattformfunktionen und der Frage, wie sich agentische KI über den gesamten Software-Lebenszyklus hinweg einsetzen lässt.