Create Design Doc for Multi-Platform Gateway

Why is this change being made?

There are multiple initiatives ongoing at GitLab that can benefit from a standardized approach, and collaboration.

groupauthentication - the New Auth Stack requires a path to production, needing to understand how they can get

groupoperate - are using Envoy Gateway to handle the NGINX Ingress Retirement in March 2026, by bundling this in the GitLab Helm Chart.

groupNetworking & Incident Management - are supporting NewAuth, and have identified opportunity to deprecate HAProxy from GitLab.com and bring it in line with other GitLab product offerings.

This MR introduces a design document for establishing a standardized Multi-Platform Gateway across GitLab.com, Dedicated, Cells, and Self-Managed deployments. The document outlines a phased approach to deploy Envoy Gateway as a unified ingress layer, replacing legacy infrastructure (HAProxy, NGINX Ingress) while supporting critical initiatives like the New Auth Stack.

Key highlights:

• Phase 1 (FY27 Q1): Deploy Envoy Gateway to non-production environments and unblock Auth Architecture.
• Phase 2 (FY27 Q2): Production rollout replacing NGINX Ingress
• Phase 3 (FY27 Q3): HAProxy deprecation using a strangler pattern

Strategic benefits: Reduced operational complexity, architectural alignment across platforms, faster feature delivery, and IPv6 support

Addresses critical issues: NGINX retirement (March 2026), premature network terminations, and HAProxy maintenance burden

Related Issues and Discussions:

• Improve reliability and observability of custom... (gitlab-com/gl-infra&1641)
• Record Envoy Gateway decision (gitlab-org/charts/gitlab!4666 - merged)
• https://gitlab.com/groups/gitlab-org/-/epics/19332+

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• docs: Create Design Doc for Multi-Platform Gateway

---