- Supported formats
- Accepting contributions
- Rate limits
- Change the storage path
To use GitLab as a private repository for a variety of common package managers, use the Package Registry. You can build and publish packages, which can be consumed as dependencies in downstream projects.
The Package Registry supports the following formats:
|Package type||GitLab version|
The below table lists formats that are not supported, but are accepting Community contributions for. Consider contributing to GitLab. This development documentation guides you through the process.
|Debian||Draft: Merge Request|
|Terraform||Draft: Merge Request|
When downloading packages as dependencies in downstream projects, many requests are made through the Packages API. You may therefore reach enforced user and IP rate limits. To address this issue, you can define specific rate limits for the Packages API. For more details, see Package Registry Rate Limits.
By default, the packages are stored locally, but you can change the default local location or even use object storage.
By default, the packages are stored in a local path, relative to the GitLab installation:
- Linux package (Omnibus):
- Self-compiled (source):
To change the local storage path:
/etc/gitlab/gitlab.rband add the following line:
gitlab_rails['packages_storage_path'] = "/mnt/packages"
Save the file and reconfigure GitLab:
sudo gitlab-ctl reconfigure
production: &base packages: enabled: true storage_path: /mnt/packages
Save the file and restart GitLab:
# For systems running systemd sudo systemctl restart gitlab.target # For systems running SysV init sudo service gitlab restart
Docker and Kubernetes do not use local storage.
- For the Helm chart (Kubernetes): Use object storage instead.
- For Docker: The
/var/opt/gitlab/directory is already mounted in a directory on the host. There’s no need to change the local storage path inside the container.
Instead of relying on the local storage, you can use an object storage to store packages.
For more information, see how to use the consolidated object storage settings.
After configuring the object storage, use the following task to migrate existing packages from the local storage to the remote storage. The processing is done in a background worker and requires no downtime.
Migrate the packages.Linux package (Omnibus)
sudo gitlab-rake "gitlab:packages:migrate"Self-compiled (source)
RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:packages:migrate
Track the progress and verify that all packages migrated successfully using the PostgreSQL console.Linux package (Omnibus) 14.1 and earlier
sudo gitlab-rails dbconsoleLinux package (Omnibus) 14.2 and later
sudo gitlab-rails dbconsole --database mainSelf-compiled (source)
RAILS_ENV=production sudo -u git -H psql -d gitlabhq_production
Verify that all packages migrated to object storage with the following SQL query. The number of
objectstgshould be the same as
gitlabhq_production=# SELECT count(*) AS total, sum(case when file_store = '1' then 1 else 0 end) AS filesystem, sum(case when file_store = '2' then 1 else 0 end) AS objectstg FROM packages_package_files; total | filesystem | objectstg ------+------------+----------- 34 | 0 | 34
Finally, verify that there are no files on disk in the
packagesdirectory:Linux package (Omnibus)
sudo find /var/opt/gitlab/gitlab-rails/shared/packages -type f | grep -v tmp | wc -lSelf-compiled (source)
sudo -u git find /home/git/gitlab/shared/packages -type f | grep -v tmp | wc -l