Feature
GitLab
GitLab is removing the Dependency Proxy for packages — the feature that proxies and caches packages pulled from upstream Maven registries — in GitLab 20.0 (20 May 2027). It is replaced by the Maven virtual registry, and affected projects must repoint their package-manager configuration from the Dependency Proxy for packages endpoints to the Maven virtual registry.
departs 20 May 2027
Quick answers
- Is it true that GitLab Dependency Proxy for packages is being removed in 20.0 (20 May 2027) — migrate to the Maven virtual registry?
- Yes. GitLab has officially announced it, effective 20 May 2027. The Dependency Proxy for packages is the GitLab feature that sits in front of an upstream package registry and caches the packages your projects pull through it, so builds are faster and keep working when the upstream is slow or unreachable.
- When does it take effect?
- 20 May 2027. Verified against the vendor's own announcement.
- What should I use instead?
- Treat GitLab 20.0 (20 May 2027) as the date the Dependency Proxy for packages endpoints stop existing.
What this means for you
The Dependency Proxy for packages is the GitLab feature that sits in front of an upstream package registry and caches the packages your projects pull through it, so builds are faster and keep working when the upstream is slow or unreachable. GitLab deprecated it in the 19.1 milestone and will remove it in GitLab 20.0, which GitLab's own release schedule dates to 20 May 2027. This is a Premium/Ultimate feature, so it affects paid self-managed and SaaS groups that configured their Maven (and related) package managers to resolve through the Dependency Proxy for packages endpoints. GitLab does not mark this a breaking change and has not named an end-of-support milestone before the 20.0 removal, but once 20.0 lands the old endpoints go away, so any build or package-manager configuration still pointing at them will stop resolving dependencies through GitLab. The replacement, the Maven virtual registry, is GitLab's stated path forward — GitLab says it offers better performance, upstream proxying and caching, and deeper integration with GitLab's package workflows — but it is a different feature with its own endpoints and setup, so the migration is a configuration change you have to make, not an automatic swap.
Where to go
Treat GitLab 20.0 (20 May 2027) as the date the Dependency Proxy for packages endpoints stop existing. Before then, find every place your builds resolve packages through those endpoints — Maven `settings.xml`, `pom.xml` repository/mirror entries, CI jobs, and any shared runner or image configuration — and migrate them to the Maven virtual registry, following the Maven virtual registry documentation for the new endpoint URLs and authentication. Roll it out on a test project first and confirm dependency resolution and caching behave as expected before cutting over your main pipelines, because the two features are configured differently. Track GitLab's official removal issue (gitlab-org/gitlab#601255) for any change to the scope or the 20.0 timing.
- Maven virtual registry — GitLab's named replacement, with upstream proxying and caching (GitLab Premium/Ultimate)
- Point your package manager directly at the upstream registry (loses GitLab-side caching)
GitLab is removing the Dependency Proxy for packages in GitLab 20.0, which GitLab’s own release schedule dates to 20 May 2027. It is being replaced by the Maven virtual registry.
The Dependency Proxy for packages is the feature that proxies and caches packages your projects pull from an upstream Maven registry — making builds faster and insulating them from a slow or unreachable upstream. GitLab announced the deprecation in the 19.1 milestone and will remove it in 20.0.
Who this affects
This is a Premium/Ultimate feature, so it affects paid self-managed and SaaS groups that configured their Maven (and related) package managers to resolve through the Dependency Proxy for packages endpoints. GitLab does not flag this as a breaking change and lists no separate end-of-support milestone before the 20.0 removal — but once 20.0 ships, the old endpoints are gone, and any build or package-manager configuration still pointing at them stops resolving dependencies through GitLab.
What to do
GitLab’s stated path forward is the Maven virtual registry, which it says offers better performance, upstream proxying and caching, and deeper integration with GitLab’s package workflows. It is a different feature with its own endpoints and setup, so this is a configuration migration, not an automatic swap:
- Find every place your builds resolve packages through the Dependency Proxy for packages — Maven
settings.xml,pom.xmlrepository/mirror entries, CI jobs, and shared runner or image config. - Repoint them at the Maven virtual registry, using its documentation for the new endpoint URLs and authentication.
- Validate on a test project — confirm dependency resolution and caching behave as expected — before cutting over your main pipelines.
Track the official removal issue, gitlab-org/gitlab#601255, for any change to scope or the 20.0 timing.
Entry changelog
- — last reviewed.
- — Entry created from GitLab's official deprecations and removals page (docs.gitlab.com/ee/update/deprecations.html), whose embedded data lists this item as announced in milestone 19.1, removal_milestone "20.0", end_of_support_milestone empty, breaking_change false, tiers Premium/Ultimate, issue gitlab-org/gitlab#601255, replaced by the Maven virtual registry. sunsetDate 2027-05-20 taken from GitLab's own release schedule embedded on the same page ({date:"2027-05-20",version:"20.0"}) — a GitLab-published date for 20.0, not an inferred one (§3.2) — matching the sibling 20.0 entries gitlab-design-management-deprecation and gitlab-compliance-pipelines-removal. No detect: fingerprint — the going-away endpoint path appears mainly in Maven settings.xml/pom.xml, which the CLI does not scan, and a generic token would over-fire; this is hosted/config, not reliably repo-detectable.
Put this countdown in your README
Building on GitLab? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/gitlab-dependency-proxy-for-packages-deprecation)Spot an error or a changed date? Tell us and it’s corrected the same night.