TLDR; In 2024, GitLab will deliver a dependency proxy for Maven, npm, PyPI, and NuGet (stretch). In addition, we'll expand the dependency proxy for containers to work with any external container registry, not just public Docker Hub accounts.
2023 is nearly over. I'd like to take a minute to share some features for GitLab Package to look forward to in 2024. These new features will enable enterprise customers to consolidate on GitLab for artifact management, and help save money on licensing costs for JFrog/Sonatype and improve the developer experience.
As the product manager for the Package stage, I have spent the past four years talking to customers and prospects about how they can replace their Artifactory or Sonatype instance with GitLab Package. Although we have helped many smaller organizations to consolidate on GitLab, it's been a challenge to help larger, more complex organizations to do so. Why? Because larger organizations typically need to pull packages from multiple repositories. Artifactory and Nexus offer a feature called virtual registries, which act as a single access point to download, install, or deploy artifacts in the same format from one or more upstream repositories.
This functionality can:
- make pipelines faster
- make pipelines more reliable
- reduce the cost of data transfer because over time most packages will be pulled from the cache
Each dependency proxy format will give users the ability to add/configure one external repository.
Once added, when a user tries to install a package using their project-level endpoint, GitLab will first look for the package in the project and, if it's not found, attempt to pull the package from the external repository.
When a package is pulled from the external repository, it will be imported into the GitLab project so that the next time that particular package/version is pulled it's pulled from GitLab and not the external repository.
If the package is not found in their GitLab project or the external repository, GitLab will return an error.
- This feature and all future dependency proxy formats will be in the Premium tier.
- Project owners will be able to configure this via a project's settings (API or UI).
- We will support external repositories that require authentication, such as Artifactory or Sonatype.
To support this theme, we will also likely need to invest in related features, such as those listed in the issues below, which focus on the performance of the registry or giving more fine-grained access control to customers:
- Add a dependency proxy scope for GitLab tokens
- Improve Package Registry metadata generation
- Package registry authentication token
Today, GitLab.com is supported by the next-generation container registry and we've seen many performance and reliability improvements.
In 2024, we will focus on:
- Getting the container registry to GA for self-managed customers
- Improving the UI/UX of the container registry
- Adding support for granular access protection for container registries and immutable container image tags
- Adding an integration with Google Cloud Platform's Artifact Registry to help make deploying container images from GitLab to GCP easy
This functionality will:
- help customers to reduce their storage costs
- make the container registry more performant and reliable
- make the GitLab team more efficient (by avoiding maintaining two codebases)
We have exciting plans for 2024! Please follow along as we make the package and container registries more useful, easier to use, and more secure.
Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.