Make Redis a hard dependency for the Container Registry

Summary

Currently, Redis is an optional dependency for the Container Registry, but several experimental features require it for different reasons. This creates operational inconsistency and complexity for users who need to make configuration decisions about whether to enable Redis-dependent features.

Background

As discussed in !2432 (merged), we have multiple experimental features that depend on Redis:

  1. Database metrics collection - Uses Redis-based distributed locking to ensure only one registry instance collects metrics in a cluster
  2. Database load balancing - Also experimental, disabled by default, and dependent on Redis for coordination
  3. Renaming/moving GitLab projects with registry data - Relies on Redis for distributed locking.

The current optional Redis dependency creates several issues:

  • Operational inconsistency: Some advanced features require Redis while core functionality doesn't
  • Configuration complexity: Users must decide whether they need Redis based on which features they want to use
  • Feature graduation blockers: Experimental features can't graduate to generally available while their dependencies remain optional
  • Contradicts product principles: Goes against GitLab's "Convention over configuration" principle

Proposal

Make Redis a hard dependency for operating the Container Registry. This would:

Benefits

  1. Graduate experimental features: Allow database metrics collection and load balancing to move from experimental to generally available
  2. Consistent operational experience: All installations would have the same infrastructure requirements
  3. Enable future features: Provide a foundation for other distributed coordination features (e.g., cleanup policies)
  4. Simplify documentation: Remove complex conditional setup instructions
  5. Align with product principles: Reduce configuration decisions users need to make

Implementation Considerations

  • Breaking change: This requires a major version bump as it changes infrastructure requirements
  • Tooling: Requires Distribution changes to configure the Redis connection by default
  • Timing: Coordinate with GitLab release cycles and customer communication
  • Documentation: Update all operational guides to reflect the new requirement

Acceptance Criteria

  • Plan timeline for making Redis mandatory
  • Identify which version will introduce this breaking change
  • Add provisioning/configuration support to Distribution projects
  • Create documentation for existing installations
  • Update all configuration examples and documentation
  • Graduate dependent experimental features to GA
  • Communicate breaking change to customers well in advance
  • Consider providing Redis setup guidance/tooling for easier adoption

Impact

Positive:

  • Simplified operational model
  • Consistent feature availability across installations
  • Foundation for advanced distributed features
  • Better alignment with GitLab's architectural patterns

Considerations:

  • Additional infrastructure requirement for simple deployments
  • Breaking change requiring careful migration planning
  • Need for customer communication and support during transition

This architectural decision will significantly improve the operational experience and enable the Container Registry to provide more advanced, reliable features across all installations.

Edited by João Pereira