Published on: March 31, 2026
5 min read
GitLab's package hosting infrastructure has changed. Learn what actions to take before old URL formats are deprecated in September 2026.

Over the past few months, we have been gradually migrating the infrastructure behind packages.gitlab.com to a new package hosting system.
The base domain packages.gitlab.com remains the same, but URL formats, GPG key locations, network requirements, and the package browsing UI are changing. Your existing configuration will continue to work during the transition period until September 30, 2026 — we are maintaining backwards compatibility with old URL formats through URL rewrite rules while customers transition.
The updated installation documentation already reflects the new URL formats. If you are setting up a new installation, follow the documentation and no further action is needed.
If you have an existing installation, read on for what's changing and what you need to do.
The old PackageCloud system and its UI will be shut down on March 31, 2026. Since all traffic has been served from the new system for months, we do not expect any disruptions.
The URL rewrite rules maintaining backwards compatibility will be removed by the end of September 2026. After that date, only the new URL formats will work.
We recommend updating your configurations as soon as possible.
Before the end of September 2026, you need to:
gitlab/* repos to use the new URL formats.https://packages.gitlab.com/gpg.key to https://packages.gitlab.com/gpgkey/gpg.key.https://storage.googleapis.com/packages-ops.noarch RPM references from the noarch path to x86_64, if you use Runner noarch RPM packages.download.rpm or download.deb URLs.Read on for the details behind each change.
gitlab/* reposFor gitlab/* repositories (e.g., gitlab-ee, gitlab-ce), the DEB repository URL structure now includes the distribution codename as a path segment. This aligns with the standard Debian repository format, where the distribution codename is part of the base URL that your package manager uses to locate package metadata and pools. The old PackageCloud format omitted this path segment.
The easiest way to update is to re-run the installation script, which will automatically configure the correct repository URLs:
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash
Replace gitlab-ee with the appropriate repository name (e.g., gitlab-ce). For RPM-based systems, use script.rpm.sh instead.
If you prefer to update your configuration manually, here is what changed. For example, for GitLab EE on Ubuntu Jammy:
Old format (to be deprecated):
deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/ jammy main
This resolved to paths like:
/gitlab/gitlab-ee/ubuntu/dists/jammy/...
/gitlab/gitlab-ee/ubuntu/pool/...
New format:
deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/jammy jammy main
Which resolves to:
/gitlab/gitlab-ee/ubuntu/jammy/dists/jammy/...
/gitlab/gitlab-ee/ubuntu/jammy/pool/...
Note the addition of the distribution codename (jammy) as a path segment before dists/ and pool/.
runner/* reposThe URL format for runner/* DEB repositories (e.g., runner/gitlab-runner) are unchanged. No action is needed.
The GPG key URL has changed. Update any references in your configuration:
| Old URL | New URL | |
|---|---|---|
| GPG key | https://packages.gitlab.com/gpg.key | https://packages.gitlab.com/gpgkey/gpg.key |
Do not reuse old installation scripts. If you have previously saved copies of the installation scripts, download the latest versions:
DEB-based (Debian/Ubuntu):
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash
RPM-based (RHEL/CentOS/etc.):
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash
Replace gitlab-ee with the appropriate repository name (e.g., gitlab-ce).
The old PackageCloud UI exposed download links in a format like /<org>/<repo>/packages/<distro>/<os>/<filename>.<ext>/download.<ext> (e.g., download.deb, download.rpm). The new UI links directly to the actual package paths instead.
If you navigate packages through the new UI, no action is needed. However, if you have automation that scrapped the old UI or relied on the download.deb / download.rpm URL format, you will need to update it to use the new path structure or switch to standard package manager repository access.
noarch RPM package changesGitLab Runner noarch RPM packages (such as gitlab-runner-helper-images) have been moved from the noarch architecture path to x86_64. For example:
Old path:
/<org>/<repo>/<distro>/<os>/noarch/Packages/...
New path:
/<org>/<repo>/<distro>/<os>/x86_64/Packages/...
This change only affects RPM-based distributions (e.g., EL/8, EL/9). DEB-based Runner packages are not affected.
If you have automation or configuration that references the noarch path for Runner RPM packages, update it to use x86_64 instead.
Package downloads from packages.gitlab.com now redirect to Google Cloud Storage. Previously, packages were served through AWS CloudFront. If your environment has strict firewall or proxy rules, you must add the following to your allowlist:
https://storage.googleapis.com/packages-ops
Without this change, package downloads may fail with 503 errors or connection timeouts.
If you mirror GitLab package repositories using tools like apt-mirror, reposync, or Red Hat Satellite, you must update to the new URL format for gitlab/* repos. The old URL format does not work correctly for mirroring with the new infrastructure. More detailed instructions can be found on the installation guide.
The package browsing interface at packages.gitlab.com is being updated with a new UI. The old interface (previously accessible at packages.gitlab.com/gitlab/... and packages.gitlab.com/runner/... ) will no longer be available. The new interface provides similar package browsing functionality.
If you encounter any issues related to these changes, please report them in our public feedback issue. We are actively monitoring it and will respond to reports.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback