Skip to content
Chimera readability score 0.5687 out of 100, reading level.

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.
Timeline
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.
Required actions
Before the end of September 2026, you need to:
- Re-run the installation script (DEB or RPM) or manually update repository configurations for
gitlab/*
repos to use the new URL formats. - Update GPG key references from
https://packages.gitlab.com/gpg.key
tohttps://packages.gitlab.com/gpgkey/gpg.key
. - Update firewall/proxy allowlists to permit traffic to
https://storage.googleapis.com/packages-ops
. - Update mirroring configurations to use the new URL formats, if you mirror GitLab package repositories.
- Update Runner
noarch
RPM references from thenoarch
path tox86_64
, if you use Runnernoarch
RPM packages. - Update any direct download automation, if you relied on PackageCloud-style
download.rpm
ordownload.deb
URLs.
Read on for the details behind each change.
What's changing
DEB repository URLs for gitlab/*
repos
For 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/
.
DEB repository URLs for runner/*
repos
The URL format for runner/*
DEB repositories (e.g., runner/gitlab-runner
) are unchanged. No action is needed.
GPG key URL
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 |
Installation scripts
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
).
Direct package download URLs
The old PackageCloud UI exposed download links in a format like ///packages///./download.
(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.
GitLab Runner noarch
RPM package changes
GitLab 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:
/////noarch/Packages/...
New path:
/////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.
Firewall and network allowlist updates
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.
Repository mirroring
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.
UI changes
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.
Feedback
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.

Facts Only

Actor: GitLab
Changes: URL formats, GPG key locations, network requirements, package browsing UI
Timeline: Gradual migration over months; old PackageCloud system shutdown on March 31, 2026; URL rewrite rules removal by end of September 2026
Affected parties: GitLab customers with existing installations
Required actions: Update configurations, GPG key references, firewall/proxy allowlists, mirroring configurations, Runner noarch RPM references, and direct download automation

Executive Summary

GitLab is transitioning its package hosting system, with the base domain packages.gitlab.com remaining unchanged. The new URL formats, GPG key locations, network requirements, and package browsing UI are changing. Customers have until September 30, 2026, to update their configurations to avoid disruptions after the old PackageCloud system is shut down in March 2026.

Full Take

Patterns detected: ARC-0024 Ambiguity (the article does not explicitly state why the change is happening), ARC-0043 Motte-and-Bailey (the transition period maintains backwards compatibility while customers transition).
Steelman: GitLab is making a gradual shift to a new package hosting system with improved infrastructure and updated URL formats. They are giving customers until September 2026 to update their configurations to avoid disruptions after the old PackageCloud system is shut down in March 2026.
Root cause: The transition may be driven by GitLab's desire to improve its package hosting service and align with standard Debian repository format conventions.
Implications: Customers need to update their configurations to ensure continued functionality, which could potentially lead to increased complexity or potential errors if not done correctly.
Bridge questions: How can customers ensure a smooth transition without disruptions? What tools or resources are available to assist with the configuration updates? What challenges might arise during this transition period, and how can they be addressed effectively?

Sentinel — Human

Confidence

Based on stylometric analysis, the coherence of the arguments presented, and absence of known template patterns, it is likely that this text was authored by a human.

Signals Detected
low severity: Sentence length variance is erratic, showing signs of human writing
high severity: The text demonstrates a clear narrative and personal voice, suggesting a human author
medium severity: While the content follows a logical structure, it does not seem to match any known template patterns
Human Indicators
The text provides specific and detailed information about changes in URL formats and GPG key locations, which suggests human authorship
Changes to packages.gitlab.com: What you need to know — Arc Codex