Our goal is for you to rely on GitLab as a universal package manager, so that you can reduce costs and drive operational efficiencies. The backbone of this category is your ability to easily publish and install packages, no matter where they are hosted.
You can view the list of supported and planned formats in our documentation here.
This page is maintained by the Product Manager for Package, Tim Rizzi (E-mail)
We are currently focused on two epics for the GitLab Package Registry.
First, we'll improve our reporting and accuracy of how much storage is being consumed by the Package Registry. The epic gitlab-#1422 details our plan to achieve this.
The second, gitlab-#2867 will move the Package Registry to GitLab Core, so you can rely on GitLab for all of your Package management needs, regardless of your pricing tier.
This category is currently at the "Viable" maturity level, and our next maturity target is "Complete" (see our definitions of maturity levels).
For a list of key deliverables and expected outcomes, check out the epic, gitlab-#2891, which includes links and expected timing for each issue.
Artifactory and Nexus are the two leading univeral package manager applications on the market. They both offer products that support the most common formats and additional security and compliance features. A critical gap between those two products and GitLab's Package offering is the ability to easily connect to and group external, remote registries. To date, GitLab has been focused on delivering Project and Group-level private package registries for the most commonly used formats. We plan on bridging this gap by expanding the Dependency Proxy to support remote and virtual registries.
Azure and AWS both offer support for hosted and remote registries for a limited amount of formats.
GitHub offers a package management solution as well. They offer project-level package registries for a variety of formats. On their roadmap for Q4 2020 and Q1 2021 they will add support for GitHub Enterprise and GitHub private instances. They have implementations with Composer and PyPI planned but not scheduled. They charge for storage and network transfers. GitHub does a nice job with search and reporting usage data on how many times a given package has been downloaded. They do not have anything on their roadmap about supporting remote and virtual registries, which would allow them to group registries behind a single URL and allow them to act as a universal package manager, like Artifactory or Nexus or GitLab.
The below table lists our supported and most frequently requested package manager formats. Artifactory and Nexus both support a longer list of formats, but we have not heard many requests from our customers for these formats. If you'd like to suggest we consider a new format, please open an issue here.
GitLab | Artifactory | Nexus | GitHub | Azure Artifacts | AWS CodeArtifact | |
---|---|---|---|---|---|---|
Composer | ✔️ | ✔️ | ✔️️️️ | - | - | - |
Conan | ✔️ | ✔️ | ☑️ | - | - | - |
Debian | - | ✔️ | ✔️ | - | - | - |
Maven | ✔️ | ✔️ | ✔️ | ️✔️ ️ | ✔️ | ✔️ |
NPM | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
NuGet | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | - |
PyPI | ✔️ | ✔️ | ✔️ | - | ✔️ | ✔️ |
RPM | - | ✔️ | ✔️ | - | - | - |
RubyGems | - | ✔️ | ✔️ | ✔️ | - | - |
☑️ indicates support is through community plugin or beta feature
Interested in contributing a new format? Please check out our suggested contributions.
gitlab-#2614, captures our plan to improve our existing integrations by expanding our existing product to include the creation, management and usage of remote and virtual repositories.