Next-generation GitLab container registry goes GA

Last year, we embarked on an ambitious journey to re-architect the GitLab container registry and unlock powerful new capabilities like zero-downtime garbage collection. After successfully migrating GitLab.com to this next-generation registry, we opened up a beta program for self-managed customers to test out the new architecture and provide feedback.

The results from the beta program have been outstanding – participants are already realizing major benefits, including the following:

• significant storage cost and maintenance time savings from efficient zero-downtime garbage collection, with no required downtime or manual interventions
• improved performance and reliability for tag cleanup policies and the container registry API and UI
• early access to new features like better sorting/filtering and storage usage visibility

Based on the positive feedback and successful migrations during the beta, we are excited to announce that the next-generation GitLab container registry will become generally available – but off by default – for self-managed deployments starting with GitLab 17.3.

Below are the goals and non-goals for reaching this point. The goals are what we need to have in place to officially call this feature GA. The non-goals clarify what will not be present or required at the start of GA support for bringing your own database; however, these features may be added later.

Goals

• The import process is free of known bugs.
• Import documentation reflects known best practices and addresses feedback from the beta program.
• Registry API, metadata database, and zero-downtime garbage collection are stable and reliable.
• Able to automatically apply database schema migrations for Charts installs during upgrades.
• Provide registry database as an opt-in improvement.

Non-goals

• Automatically provision registry database.
• Automatically apply database schema migrations for omnibus installs during upgrades.
• Automatically import object storage data.
• Provide Geo support to ensure your registry is highly available.

For existing self-managed instances, here's what you can expect:

• In GitLab 17.3, the new registry will be included, but disabled by default to allow time for planning migrations.
• Enabling the database will be an opt-in process outlined in the documentation.
• The legacy container registry will still receive security updates, but new features and improvements will only be developed for the next-gen version.
• We will target GitLab 19.0 for the legacy registry to stop being supported after over a year of co-existence.
• Our goal is to make this transition as seamless as possible while putting customers in control of their migration timeline. The documentation covers all the details on how to plan and execute the move to the next-gen registry.

This architectural investment lays the foundation for an even more powerful container registry experience in the years ahead. Some of the significant improvements on our roadmap include:

• protected repositories and immutable tags
• improved Helm chart management
• improved support for signing and attestations
• many more UX/UI enhancements are only possible with the database architecture

We couldn't have reached this GA milestone without the valuable feedback from our beta participants. As always, please continue to share your experiences so we can make the GitLab container registry an indispensable part of your DevSecOps toolchain.

You can try the container registry today with a free, 30-day trial of GitLab Ultimate.