Flows: Allow alternate container registry configuration for enterprise environments

Problem Statement

Foundation flows (e.g., "Fix Pipeline") are completely unusable in enterprise environments that block external container registries. The flows are hardcoded to pull executor images from registry.gitlab.com, which is forbidden in many regulated enterprise networks.

Customer Impact

A major financial institution (Ultimate, Self-Managed 18.5) reported on Dec 8, 2025:

"This feature is currently unusable in our environment."

"The flow is pre-defined, and no way for us to change anything. When triggered, this flow tries to download the image from registry.gitlab.com, which is forbidden in our network. We provide users with our own custom built images, and would like that to be used."

Error observed:

ERROR: Job failed: failed to pull image "registry.gitlab.com/gi..."

Why This Is Critical

Factor Impact
Complete Feature Blocker "Fix Pipeline" foundation flow is 100% unusable
No Workaround Available Foundation flows are hardcoded - admins cannot override
Enterprise Pattern Major banks/enterprises block external registries by default
Air-gapped Networks Cannot reach registry.gitlab.com at all
Compliance Requirements Only approved, internally-scanned images allowed
Self-Managed Focus DAP for self-managed is a key differentiator - this breaks it

Affected Customers

  • Multiple enterprise customers - Confirmed blocked (Dec 2025)
  • Likely affected: Any enterprise with:
    • Network egress restrictions
    • Air-gapped or restricted network environments
    • Security policies requiring internal container registries
    • Compliance requirements for pre-approved images only

Current Behavior

  1. User triggers "Fix Pipeline" foundation flow
  2. Flow attempts to pull executor image from registry.gitlab.com
  3. Network policy blocks the request
  4. Job fails with failed to pull image error
  5. No admin override possible - flow definition is hardcoded

Expected Behavior

Admins should be able to configure alternate container registries for foundation flow executors at:

  1. Instance level - Default registry for all foundation flows
  2. Group/Project level - Override for specific namespaces
  3. Flow-specific - Override for individual foundation flows

Chosen Solution

Option A: Instance-Level Configuration (Minimum Viable, Chosen Solution)

Add admin setting under Admin > Settings > CI/CD or Admin > Settings > Duo Agent Platform:

Foundation Flow Executor Registry: [____________]
Default: registry.gitlab.com

Alternative Solutions

Option B: Hierarchical Configuration (Potential Follow up)

Allow configuration at multiple levels with inheritance:

Level Setting Example
Instance duo_agent_platform.foundation_flow_registry internal-registry.example.com
Group Override instance default team-registry.example.com
Project Override group default project-specific-registry.example.com

Option C: Mirror Documentation (Can be used as individual fallback for affected customers)

Document how enterprises can:

  1. Mirror GitLab's foundation flow images to internal registry
  2. Configure GitLab Runner to use registry mirrors
  3. Use pull-through cache proxies

Technical Considerations

  • Foundation flow executor images need to be published with versioned tags
  • Image digests should be documented for security scanning
  • Consider Helm chart values for Kubernetes deployments
  • Runner configuration may need pull_policy adjustments

Acceptance Criteria

  • Admin can configure alternate container registry for foundation flows
  • Configuration works at instance level (minimum)
  • Foundation flows use configured registry instead of registry.gitlab.com
  • Documentation updated with enterprise deployment guidance
  • Migration path documented for existing deployments

Customer Request

"A way for admins to predefine the foundation flows would be a good feature for self-managed." — Enterprise customer, Dec 2025

  • This is part of broader enterprise readiness for DAP
  • Similar patterns exist for GitLab Runner registry configuration
  • Affects all foundation flows, not just "Fix Pipeline"
Edited by Sebastian Rehm