GitLab Launches Artifact Central Beta, One Registry for an Entire Organization

Why GitLab built a single registry

GitLab announced the beta at its Transcend event. The company argues that every software build is assembled from open source packages, base images and libraries, with a team's own code on top, and that a missing or drifted component makes the build fail. According to GitLab, such failures multiply at agent speed, and no team can clear them as manual exceptions.

The company also points to registry sprawl. In GitLab today, retention rules, storage limits and publishing access are configured separately inside each project's package and container registry. GitLab says that design works when a person sets up each registry by hand, but breaks down when agents run continuously across hundreds of projects.

Policy at the organization level and three repository types

Artifact Central moves configuration up one level. Teams assign retention rules, quota settings and access policies once for the organization instead of recreating them in every project. Every repository is closed by default, and organization membership alone does not unlock any repository until a role grants access. GitLab has created four artifact-specific roles: Admin, Manager, Contributor and Viewer. They are kept separate from existing project roles, so granting repository access does not change a person's privileges elsewhere.

Developers use a single URL through three repository types:

• Hosted: private packages and images that teams build and publish.
• Remote: a proxy in front of an external source such as Docker Hub or Maven Central, with the connection tested before anything depends on it.
• Virtual: a single endpoint combining hosted and remote repositories. GitLab checks the hosted repository first, then falls back to the remote source, and the first external pull is cached.

During the beta, Artifact Central supports Maven, npm, Docker and OCI, with more formats to follow.

Built-in provenance and shared authentication

Because the registry sits in the same platform that ran the build, artifacts published through Artifact Central automatically carry their provenance: which pipeline built them, which branch and commit they came from, and who triggered the job. GitLab contrasts this with standalone registries, where tracing an artifact means correlating IDs across a CI system and a registry with a script someone has to maintain.

Publishing and pulling use CI_JOB_TOKEN, the identity pipelines already have, for people and agents alike. GitLab says an agent uses that same job token rather than a separate service account with its own permissions.

GitLab also plans to connect this information across an organization through GitLab Orbit, so a question such as which running services are affected by a vulnerability becomes a single query.

Dependency Firewall and migration

GitLab Dependency Firewall, a separate product now in early access for Premium and Ultimate customers, works with Artifact Central out of the box. It is meant to stop risky packages before they reach a build, and is added to each pipeline using the glab CLI. GitLab plans tighter integration so that one organization-wide policy can block packages by vulnerability, license or package age when they are pulled.

For migration, teams can add existing repositories as remotes behind a virtual repository. Artifacts move over only when a build asks for them, the old registry remains the system of record, and teams can later convert a remote into a hosted repository. GitLab says this avoids bulk copies and weekend migration windows.

Availability and what it means for teams

Artifact Central is available in beta for GitLab.com, with GitLab Self-Managed availability planned for later this month, according to the company. There is no billing during the beta. GitLab says it is tracking usage to shape pricing ahead of general availability and will share details then. No invitation is needed: users sign up on the GitLab website and a team member helps enable it, and people without a GitLab account can also register for the beta.

For platform teams, the pitch is setting storage quotas and access rules once and having every repository inherit them, with one dashboard showing how much the company stores and where. For developers, it means one URL for internal and external packages and no new secrets to manage when publishing from CI.