Feature · signalled, not confirmed
GitLab
The official GitLab Helm chart and GitLab Operator are dropping their bundled Ingress controllers — NGINX Ingress, HAProxy and Traefik — with full removal planned for GitLab 20.0. Since 19.0 the chart defaults to the Kubernetes Gateway API with a bundled Envoy Gateway, and the bundled controllers are deprecated and disabled by default. GitLab has not announced a specific calendar date, only the 20.0 milestone.
departs Date not announced · signalled, not confirmed
Quick answers
- Is it true that GitLab Helm chart removes bundled NGINX Ingress, HAProxy and Traefik controllers in 20.0 — migrate to Envoy Gateway and the Gateway API?
- Not confirmed. GitLab has signalled this but has not committed to a date.
- When does it take effect?
- No date has been announced yet — GitLab has flagged the change but not set one.
- What should I use instead?
- You have two supported paths.
What this means for you
If you install self-managed GitLab with the official Helm chart (or the GitLab Operator) and rely on one of its bundled Ingress controllers — NGINX Ingress, HAProxy or Traefik — to route traffic into the deployment, that convenience is going away. GitLab is standardising on the Kubernetes Gateway API with a bundled Envoy Gateway: as of GitLab 19.0 the chart already defaults to Envoy Gateway and the bundled controllers are deprecated and disabled by default, and full removal of the bundled controllers is planned for GitLab 20.0. Separately, the bundled NGINX Ingress will not receive security patches after March 2026, so continuing to run it unchanged is a security dead end well before the removal lands. The removal is scoped to the controllers GitLab bundles in the chart — plain Kubernetes Ingress resources are not deprecated and keep working after 20.0, but you will have to bring your own externally-installed Ingress controller instead of letting the GitLab chart provide one. GitLab has not published a calendar date for 20.0, so this entry carries no fixed sunset date yet; it tracks the 20.0 milestone and will be updated when GitLab states a date.
Where to go
You have two supported paths. The recommended one is to migrate to the bundled Envoy Gateway and the Kubernetes Gateway API, which is the chart default from GitLab 19.0 onward — GitLab publishes a step-by-step "Migrate to Envoy Gateway" guide at docs.gitlab.com/charts/installation/migration/envoy_gateway_migration/. The alternative, if you want to keep using Ingress resources, is to install and run your own external Ingress controller (NGINX Ingress, HAProxy, Traefik, or another) outside the GitLab chart and point the chart at it; Ingress itself is not deprecated, only the controllers GitLab bundles. Either way, stop depending on the bundled controller before GitLab 20.0, and note that the bundled NGINX Ingress stops getting security patches after March 2026 — treat that as the practical deadline to move, not the (still unannounced) 20.0 release date.
- Bundled Envoy Gateway + Kubernetes Gateway API — the chart default since GitLab 19.0 and GitLab's recommended target
- An externally-installed Ingress controller (NGINX Ingress, HAProxy, Traefik, etc.) you manage yourself, with the GitLab chart configured to use it
The official GitLab Helm chart and GitLab Operator are removing their bundled Ingress controllers — NGINX Ingress, HAProxy and Traefik — with full removal planned for GitLab 20.0, per GitLab’s NGINX chart documentation. GitLab is standardising on the Kubernetes Gateway API with a bundled Envoy Gateway, which has been the chart default since GitLab 19.0.
GitLab has not announced a calendar date for 20.0, so this entry tracks the milestone rather than a fixed date, and carries no countdown yet.
What’s being removed
GitLab’s Helm chart has historically bundled several Ingress controllers so a fresh install could route traffic without you installing one yourself. Those bundled controllers — NGINX Ingress, HAProxy and Traefik — are being dropped. As of GitLab 19.0 the chart already defaults to Envoy Gateway and the bundled controllers are deprecated and disabled by default; 20.0 is when they are planned to be removed entirely.
Separately, the bundled NGINX Ingress stops receiving security patches after March 2026 — a hard reason to move well before the removal milestone.
Who this affects
Self-managed GitLab administrators who install via the Helm chart or Operator and depend on a GitLab-bundled Ingress controller for traffic routing. If you already run your own external Ingress controller or have moved to Envoy Gateway, you are not affected.
Plain Kubernetes Ingress resources are not deprecated — they keep working after 20.0 — but you’ll need to supply your own externally-installed controller rather than relying on the one GitLab bundled.
What to do
- Preferred: migrate to Envoy Gateway + the Gateway API. It’s the chart default from 19.0 on; follow GitLab’s Migrate to Envoy Gateway guide.
- Or bring your own Ingress controller. Install NGINX Ingress / HAProxy / Traefik (or another) outside the GitLab chart and configure the chart to use it.
- Treat March 2026 as the practical deadline. That’s when the bundled NGINX Ingress stops getting security patches — don’t wait for the (unannounced) 20.0 date to move.
This entry tracks GitLab’s 20.0 deprecation milestone; when GitLab publishes a calendar date for the removal, the entry will be updated with a changelog note.
Entry changelog
- — last reviewed.
- — Entry created from GitLab's official NGINX chart documentation, which states the bundled NGINX Ingress "is deprecated and won't receive security patches after March 2026" and that "full removal is planned for 20.0"; the bundled HAProxy and Traefik controllers are being removed on the same milestone, with the Gateway API + Envoy Gateway as the replacement (default since 19.0). No calendar date is stated for GitLab 20.0, so the entry is published as `signaled` with no sunset date per Constitution §3.2 (never infer a date) and will be updated when GitLab announces one. Not fingerprinted: a GitLab Helm values file referencing these controllers uses generic names shared by unrelated software, so a detect rule would misfire.
Put this countdown in your README
Building on GitLab? Drop this badge into a project’s README or docs — it shows the days left and
refreshes on its own every night from this page. 
[](https://lastcall.dev/entries/gitlab-helm-bundled-ingress-controllers-removal)Spot an error or a changed date? Tell us and it’s corrected the same night.