Self managed: Support Rollout of Container Registry for Self-Managed Instances
This epic tracks ~"group::operate" implementation work. For overall ~FY26::Q4 interlock status, see https://gitlab.com/groups/gitlab-org/-/epics/20188+.
## Summary
[Rollout of Container Registry for Self-Managed Instances](https://gitlab.com/groups/gitlab-org/-/epics/15872) is one of ~"group::container registry" FY26 priorities.
The container registry metadata database lacks comprehensive support for self-managed deployments including Dedicated:
* **Missing configuration support**: No automated provisioning or migration support in Omnibus, with only partial Chart implementation
* **Unassessed GA readiness**: Multiple support gaps had never been properly evaluated for Dedicated and self-managed users
* **Breaking change rollout risk**: Original strategy would have introduced disruptive changes for existing users
* **Feature gaps needed investigation**: Missing support for Backup/Restore, Geo, GitLab.com migration handling, HA configurations, and database provisioning
## Why is this important?
Covering the registry database metadata gaps is important because:
- It aims to considerably reduce infrastructure costs of our self-managed installations, by providing garbage collection system to the object storage.
- It aims to reduce GitLab instance maintenance for users with big object store usage, for the same reason as above.
- Database searches are more efficient than the filesystem searches that the legacy method uses, so our UI can benefit from faster results also.
- The registry team currently has to support 2 different code paths, metadata in filesystems (legacy code) and in databases.
- The longer we take to enable it by default, the more users will have to eventually migrate to the new solution, which currently means running a set of manual import steps.
* **Edit: Enabling it by default was assessed to be a breaking change. We decided to implement a soft-rollout strategy with a database `prefer` mode instead. See the **[**closing status**](https://gitlab.com/groups/gitlab-org/-/epics/17005#note_2916730716)**.**
## DRI
- @Alexand
### Participants (primary, secondary)
- ~"group::operate" : `@Alexand` , `@lucus.li`, `@grantyoung` `@nwestbury`
- ~"group::package registry" : `@hswimelar`, `@jdrpereira`
- ~"group::geo" : `@mkozono`, `@ibaum`
- ~"group::dedicated" : -
- ~"group::release-and-deploy" : `@skarbek`
- ~"devops::gitlab delivery" : `@WarheadsSE`
## Exit criteria
### FY26Q1
We need to investigate and identify what are the existing implementation gaps for us to be able to:
- Support the Registry database on Charts, Omnibus, and Operator.
- Support it for GET.
- Support it for Dedicated.
- Support it for Geo.
These should be answered by completing https://gitlab.com/gitlab-org/gitlab/-/issues/525473+
### Final work to be implemented by Operate
~"group::operate" to have implemented:
* Everything under https://gitlab.com/groups/gitlab-org/-/epics/17966+ sub-epic.
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8818+
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8670+
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/9082+
* Provide GET support once \~"group::Self Managed" provides DB level 4 support.
* Provide chart and Omnibus configuration support the prefer mode.
* Estimation: 2 quarters.
### Related work led by other groups, not to be tracked here
~"group::container registry"
* Everything under https://gitlab.com/groups/gitlab-org/-/epics/18011+ sub-epic.
* Maybe this one can be re-split depending on what gets here. It's not yet 100% clear to me.
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/9074+
* https://gitlab.com/gitlab-org/charts/gitlab/-/issues/6023+
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/9109+
* https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5931+
* https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5854+
* https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8900+
* Possibly simplifying the import progress.
* Issue: TBD
* Possibly improving visibility of the ongoing import process.
* **Issue:** https://gitlab.com/gitlab-org/container-registry/-/issues/1509+
~"group::container registry" to drive the discussion and work with the feature owners and with ~"group::operate" as consultant as needed:
* https://gitlab.com/gitlab-org/gitlab/-/issues/532507+
* https://gitlab.com/gitlab-org/gitlab/-/issues/535290+
* Depending on the outcome of these two, there might be more issues to in multiple projects to work on.
~"group::dedicated" to enable the registry by default once GET support is provided.
## Reference
* https://docs.google.com/document/d/1XyELGbjN75EfGepZyQlGH2wMC_evbDDvH2MM_Luwp7k/edit?tab=t.v47bj47rd5jo#heading=h.1zsmvh9j1ljr
* https://docs.google.com/document/d/1nw4UVouGZd_HxFIKf-YZDQ1crm5jJwLZgrv5EQ1-3w0/edit?tab=t.0
---
<!-- STATUS NOTE START -->
## Status 2025-12-09
We can close this epic. The previous open issues from last week were owned by other teams, not ~group::operate. They were added to this epic a long time ago because the team was still learning how the Grand Review works and what were its expectations. These remaining work is owned by other groups, and ~"group::container registry" will be coordinating with them through the epic: https://gitlab.com/groups/gitlab-org/-/epics/20188+
There are a couple of follow-ups for Operate, but they should not block the rollout of the registry on 19.0. I've created https://gitlab.com/groups/gitlab-org/-/epics/20218+ as a follow-up discussion.
A more complete closing statement is here: https://gitlab.com/groups/gitlab-org/-/epics/17005#note_2916730716
_Copied from https://gitlab.com/groups/gitlab-org/-/epics/17005#note_2940639504_
<!-- STATUS NOTE END -->
epic