Package registry

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
History

With the GitLab package registry, you can use GitLab as a private or public registry for a variety of supported package managers. You can publish and share packages, which can be consumed as a dependency in downstream projects.

Package workflows

Learn how to use the GitLab package registry to build your own custom package workflow:

View packages

You can view packages for your project or group:

  1. Go to the project or group.
  2. Go to Deploy > Package registry.

You can search, sort, and filter packages on this page. You can share your search results by copying and pasting the URL from your browser.

You can also find helpful code snippets for configuring your package manager or installing a given package.

When you view packages in a group:

  • All packages published to the group and its projects are displayed.
  • Only the projects you can access are displayed.
  • If a project is private, or you are not a member of the project, the packages from that project are not displayed.

To learn how to create and upload a package, follow the instructions for your package type.

Authenticate with the registry

Authentication depends on the package manager being used. To learn what authentication protocols are supported for a specific package type, see Authentication protocols.

For most package types, the following credential types are valid:

  • Personal access token: authenticates with your user permissions. Good for personal and local use of the package registry.
  • Project deploy token: allows access to all packages in a project. Good for granting and revoking project access to many users.
  • Group deploy token: allows access to all packages in a group and its subgroups. Good for granting and revoking access to a large number of packages to sets of users.
  • Job token: allows access to packages in the project running the job for the users running the pipeline. Access to other external projects can be configured.
  • If your organization uses two-factor authentication (2FA), you must use a personal access token with the scope set to api.
  • If you are publishing a package by using CI/CD pipelines, you must use a CI/CD job token.

When configuring authentication to the package registry:

  • If the Package registry project setting is turned off, you receive a 403 Forbidden error when you interact with the package registry, even if you have the Owner role.
  • If external authorization is turned on, you can’t access the package registry with a deploy token.

Use GitLab CI/CD

You can use GitLab CI/CD to build or import packages into a package registry.

To build packages

You can authenticate with GitLab by using the CI_JOB_TOKEN.

To get started, you can use the available CI/CD templates.

For more information about using the GitLab package registry with CI/CD, see:

If you use CI/CD to build a package, extended activity information is displayed when you view the package details:

Package CI/CD activity

You can view which pipeline published the package, and the commit and user who triggered it. However, the history is limited to five updates of a given package.

To import packages

If you already have packages built in a different registry, you can import them into your GitLab package registry with the package importer.

For a list of supported packages, see Importing packages from other repositories.

Reduce storage usage

For information on reducing your storage use for the package registry, see Reduce package registry storage use.

Turn off the package registry

The package registry is automatically turned on.

On a GitLab Self-Managed instance, your administrator can remove the Packages and registries menu item from the GitLab sidebar. For more information, see GitLab package registry administration.

You can also remove the package registry for your project specifically:

  1. In your project, go to Settings > General.
  2. Expand the Visibility, project features, permissions section and disable the Packages feature.
  3. Select Save changes.

The Deploy > Package registry entry is removed from the sidebar.

Package registry visibility permissions

Project permissions determine which members and users can download, push, or delete packages.

The visibility of the package registry is independent of the repository and can be controlled from your project’s settings. For example, if you have a public project and set the repository visibility to Only Project Members, the package registry is then public. Turning off the Package registry toggle turns off all package registry operations.

Project visibilityActionMinimum role required
PublicView package registryN/A. Anyone on the internet can perform this action.
PublicPublish a packageDeveloper
PublicPull a packageN/A. Anyone on the internet can perform this action.
InternalView package registryGuest
InternalPublish a packageDeveloper
InternalPull a packageGuest (1)
PrivateView package registryReporter
PrivatePublish a packageDeveloper
PrivatePull a packageReporter (1)

Allow anyone to pull from package registry

History

To allow anyone to pull from the package registry, regardless of project visibility:

  1. On the left sidebar, select Search or go to and find your private or internal project.
  2. Select Settings > General.
  3. Expand Visibility, project features, permissions.
  4. Turn on the Allow anyone to pull from package registry toggle.
  5. Select Save changes.

Anyone on the internet can access the package registry for the project.

Disable allowing anyone to pull

Prerequisites:

  • You must be an administrator.

To hide the Allow anyone to pull from package registry toggle globally:

Anonymous downloads are turned off, even for projects that turned on the Allow anyone to pull from Package Registry toggle.

Several known issues exist when you allow anyone to pull from the package registry:

  • Endpoints for projects are supported.
  • NuGet registry endpoints for groups are supported. However, because of how NuGet clients send the authentication credentials, anonymous downloads are not allowed. Only GitLab users can pull from the package registry, even if this setting is turned on.
  • Maven registry endpoints for groups are supported.
  • Terraform module registry endpoints for namespaces are supported.
  • Other group and instance endpoints are not fully supported. Support for group endpoints is proposed in epic 14234.
  • It does not work with the Composer, because Composer only has a group endpoint.
  • It works with Conan, but using conan search does not work.

Audit events

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
History

Create audit events when a package is published or deleted. Namespace Owners can turn on the audit_events_enabled setting through the GraphQL API.

You can view audit events:

Accepting contributions

The following table lists unsupported package manager formats that we are accepting contributions for. See the development guidelines to learn how to contribute to GitLab.

FormatStatus
Chef#36889
CocoaPods#36890
Conda#36891
CRAN#36892
Opkg#36894
P2#36895
Puppet#36897
RPM#5932
SBT#36898
Swift#12233
Vagrant#36899