Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Usecase: Package

Who to contact

Product Marketing Technical Marketing Product Management
Parker Ennis ( @parker_ennis ) Itzik Gan-Baruch ( @iganbaruch ) Tim Rizzi (@trizzi)

The Market Viewpoint

Package management

As an Admin at a large, enterprise organization you need to enable your developers to point their tools like Maven, npm,or pip at a local proxy server for all of the dependencies that they need. The server must be able to fetch dependencies from remote repositories, cache the artifacts, and be able to export its database of them to an air-gapped system at a regular interval. You need the ability to easily apply policies when dependencies are initially downloaded—either scanning them for security vulnerabilities or applying some other selection criteria (allowable license, allowable package author, etc.).

Well the air-gapped requirement might be a bit much, the above is what I typically hear from our customers. You can just as easily add in requirements like geo-replication, high-availability, and auditing. If you are a large organization, you need help with package management. Why large organizations? Well, smaller development teams can typically work with the myriad of package manager solutions out there because they likely:

For large organizations:

I guess you can surmise from reading the above that the problem of package management is tough for large, complex organizations. So, why make it harder by spending more money on additional tools. The trend towards consolidation make sense. It's why companies like JFrog and Sonatype have been striving to expand their products from universal package managers to complete DevOps platforms.

GitLab can save you money and time with the GitLab Package offering. In the below article, we'd like to walk you through the requirements of a package management tool, how GitLab compares to the competition, and how you should evaluate vendors.


The personas for this use case are going to focus on large, complex organizations that need a tool for securely managing dependencies in a variety of formats from many different sources.

User personas


  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟨 Priyanka - Platform Engineer
  4. 🟨 Simone - Software Engineer in Test
  5. 🟨 Delaney - Development Team Lead
  6. 🟨 Rachel - Release Manager
  7. ⬜️ Central IT / System Admins

Medium Term (1-2 years)

As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.

  1. 🟩 Priyanka - Platform Engineer
  2. 🟩 Sasha - Software Developer
  3. 🟩 Devon - DevOps Engineer
  4. 🟩 Allison - Application Ops
  5. 🟩 Simone - Software Engineer in Test
  6. 🟩 Delaney - Development Team Lead
  7. 🟩 Rachel - Release Manager
  8. 🟨 Ops Teams
  9. ⬜️ Central IT / System Admins

Software Developer Sacha

Software developers have expertise in all sorts of development tools and programming languages; an invaluable skillset to help ensure usability and consistency throughout the entire application development process and software development ecosystem while managing packages, storing and distributing images, and more.

DevOps Engineer Devon

DevOps Engineers have a deep understanding of their organization's SDLC and provide support for infrastructure, environments, and integrations.

Questions I frequently hear from customers

  1. Do you support the formats I need?
  2. Can I pull dependencies from external sources? Are they cached?
  3. Can I prevent dependencies with known vulnerabilities from ever being downloaded?
  4. Can the dependencies be made available reliably for my organization? (multi-region, highly available, air-gapped)
  5. OK, but we really rely on this, is it reliable?
  6. Is it secure?
  7. We have many terabytes of dependencies, can you handle that?
  8. We have millions of downloads/uploads per day, can you handle that?
  9. We also need the ability to audit the logs and know who/what/when/how packages have been uploaded or downloaded.
  10. My organization destroys the current instance of GitLab before installing the new version. Are my packages backed up?
  11. How the heck are we going to migrate our existing packages from vendor x to GitLab?
  12. Beyond the migration, how are we going to update all of our pipelines and cookbooks.
  13. I'm kind of a stickler Meseeks, how available is the product really?
  14. Does it integrate easily with CI?
  15. Can I manage storage easily?
  16. I need to be able to make the repository private but the registry public?
  17. I work for a center of excellences at a large organization, is there a way to put a big ol' badge on a dependency so the developers know what's available to them and pick the right dependencies.
  18. Can you help me to avoid dependency confusion and typosquatting attacks?
  19. Can you tell me how permissions work?
  20. I want packages to be immutable objects, is that how GitLab works?
  21. What about customer support?
  22. Is it easy to get started?
  23. Do the docs make sense?
  24. What happens if the registry goes down?
  25. Is anybody using GitLab's offering? Do they like it?
  26. How should I tag things?
  27. Is there an API?
  28. Can I view packages and their build data?
  29. Can I see when something has gone wrong?
  30. Can I search for a package by name/version/type/description/commit/build/ really anything
  31. Can I upload a package through the app?
  32. Does the app warn me when a package is not compliant or contains a known vulnerability?

Market Requirements

Market Requirement Description
1) Package Registry The GitLab Package Registry acts as a private or public registry for a variety of common package managers. You can publish and share packages, which can be easily consumed as a dependency in downstream projects.
2) Container registry A highly scalable application that stores and lets you distribute Docker images.
3) API An API for all features is required for supporting your customer workflows.
4) Storage management Dependencies can build up fast. You need a way to manage storage costs.
5) Extensive metadata Dependency metadata is required to validate you are using the correct one.
6) Dependency scanning Automatically find security vulnerabilities in your dependencies while you’re developing and testing your applications.
7) Dependency firewall Prevent the introduction of security vulnerabilities from external dependencies
8) Virtual registries A collection of local, remote, and other virtual repositories accessed through a single logical URL. This hides the access details of the underlying repositories letting users work with a single, well-known URL.
9) High availability A highly available product will ensure your teams stay productive
10) Geo replication You can set up a Docker Registry on your secondary Geo site that mirrors the one on the primary Geo site.
11) Searchable dependencies It should be easy to search for and discover dependencies.
12) Certified dependencies (or images) Protect important dependencies from being corrupted or overridden.

The GitLab Solution

In the past two years, we've delivered a ton of features with a relatively small team. In the next two years, we are going to accelerate our product roadmap to deliver a solution that delivers all of the market requirements for a universal package manager.

We will do this by growing the Package team, building products that are aligned with your needs, and continuing to grow and support the GitLab Community.

Discovery Questions

More content to come as we iterate

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license