Every artifact your teams ship, assembled right the first time

Every software build is assembled from open source packages, base images, and libraries, with your code on top. When one of those components is missing or has drifted, the build fails. At agent speed, those failures multiply, and no team can clear them as manual exceptions.

Project-by-project registry sprawl makes it worse because retention rules, storage limits, and publish access all live separately inside each project. Project-level design works when a person sets up each registry by hand, but breaks down when agents are running continuously across hundreds of projects.

At GitLab Transcend today, we announced GitLab Artifact Central: one organization-level registry that replaces hundreds of project-level ones, so every pull or publish by a human or an agent runs through the same governed door, enabling platform teams to assemble the right software the first time.

Here is more on why we developed Artifact Central, and how it can help your team.

Set policy once, enforce everywhere

In GitLab, retention rules, storage limits, and who can publish all live inside each project’s free package and container registry, configured on its own. GitLab Artifact Central moves that job up one level. Teams assign retention rules, quota settings, and access policies once at the organization level, instead of recreating them in every project underneath it.

Every repository is closed by default: Being a member of the organization is the gate, not the grant. Organization membership alone doesn't unlock a single repository until a role grants it. We’ve built four roles specifically for artifacts: Admin, Manager, Contributor, and Viewer. These roles are kept separate from GitLab's existing project roles, so granting someone access to a repository never touches their privileges anywhere else.

One URL for publishing, proxying, or both

Instead of navigating an internal wiki page explaining what is where, developers point to one URL for everything. GitLab Artifact Central does this through three repository types:

• Hosted — The private packages and images your teams build and publish.
• Remote — A proxy in front of an external source, like Docker Hub or Maven Central, with the connection tested before anything depends on it.
• Virtual — A single endpoint that brings hosted and remote repositories together. GitLab checks the hosted repository first, then falls back to the remote source. The first external pull is cached, so subsequent pulls come directly from GitLab without another trip to the internet.

Virtual repositories matter most for teams comparing GitLab with other artifact management solutions. They give developers the familiar single-endpoint experience without requiring them to think about where an artifact lives. Whether it was built internally or pulled from an external registry, developers request it the same way. During the beta period, Artifact Central supports Maven, npm, Docker, and OCI, with more formats to follow.

Trace anything back, automatically

Here's the part that's hard to replicate outside GitLab. Every artifact that publishes through GitLab Artifact Central carries its build provenance automatically: which pipeline built it, which branch and commit it came from, who triggered the job. Since it is the same platform that ran the build, the registry already knows.

Authentication works the same way. Publishing and pulling use CI_JOB_TOKEN, the identity your pipelines already have, for people and agents alike. An agent publishing or pulling through CI pipelines uses that exact same job token, not a bolted-on service account with separate permissions to maintain. With a standalone registry, tracing an artifact back to its source means separately correlating IDs across your CI system and your registry – using a script someone owns and maintains. With Artifact Central, the pipeline, branch, commit, and job are already attached to the artifact itself.

Answer 'what did we publish?' in seconds

Artifact Central lives in the same platform as your code, merge requests, and pipelines, so artifacts published from CI carry their build provenance: the pipeline that built them, the commit, and who published them.

Next, we plan to connect that across your organization through GitLab Orbit, so "which of my running services are affected by this vulnerability?" becomes one question with one answer, instead of a manual search across four or five tools.

Pair Artifact Central with Dependency Firewall

GitLab Dependency Firewall, a separate GitLab product now in early access for Premium and Ultimate customers, works out of the box with Artifact Central. With Dependency Firewall, you can stop risky packages before they ever reach a build. You add its check to each pipeline using the glab CLI, so coverage is pipeline by pipeline, no matter which package manager your teams use. Next, we plan to enable tighter integration between the two capabilities, so that one policy for your whole organization blocks risky packages by vulnerability, license, or package age the moment they're pulled.

Two benefits of the same registry

Here's what that looks like from two different desks: a developer shipping code, and the platform team making sure the whole thing holds together.

A developer publishing from CI. Your pipeline publishes a Maven artifact using the job token it already has without any new secrets to manage. If that same developer needs an internal package alongside something from Maven Central, they point at one virtual repo URL and let GitLab Artifact Central sort out where each one actually lives.

A platform team setting policy once. Instead of configuring rules across 100s of separate projects, an admin sets storage quotas and repository access rules at the organization level, one time — and every repository underneath inherits it. When someone asks how much the company is storing, and where, there's one dashboard with the answer.

Migrating your artifacts

Most companies aren't starting from zero, and switching cold from an existing registry isn't realistic. With GitLab Artifact Central, you can add your existing repos as remotes behind a virtual repo, so developers point at one URL and artifacts move over only when a build actually asks for one. There is no need for bulk copies, weekend migration windows, or moving petabytes of data across your network.

Your old registry remains the system of record. When you're ready, you convert that remote to a hosted repo on Artifact Central. Your migration is safer and gradual.

Try Artifact Central, free in beta

GitLab Artifact Central is available today in beta for GitLab.com, with availability on GitLab Self-Managed planned for later this month. There's no billing during the beta, and nothing to purchase. We're tracking usage to shape pricing ahead of general availability, and we'll share details then.

Help us continue to build GitLab Artifact Central

None of this would be where it is without our design partners, who've been running Artifact Central with real workflows for weeks. Their feedback already shaped what's shipping today, and your feedback will shape what comes next.

No invitation is required to participate in the beta of Artifact Central, just sign up on our website and a member of our team will be in touch to help enable it for your account. If you don’t have a GitLab account yet, you can also sign up for the beta, and a member of our team will reach out.

We can't wait to see what you build.

Watch the replay of our Transcend event to see demos of new platform capabilities and explore what it takes to carry the speed of agentic AI across the full software lifecycle.