# 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 ## Related Context - 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"