Kubernetes lost one of its most-used pieces of plumbing this year. On March 24, 2026, the community-maintained Ingress-NGINX controller officially went read-only: no more releases, no more bug fixes, no more security patches. Kubernetes SIG Network and the Security Response Committee first flagged the move in November 2025, gave the project a few months of best-effort maintenance, then pulled the plug. The Ingress API itself is still alive and well. What died is the specific controller that a huge share of clusters had quietly relied on for a decade.
That single decision reshuffled the reverse-proxy market overnight. Platform teams who had never thought twice about their ingress layer suddenly had to pick a replacement, and fast. Three names keep coming up in that search: Traefik, which has spent the past year rebuilding itself as the drop-in successor; NGINX, in its F5-maintained commercial form, which is a separate project from the one that got retired; and HAProxy, the load-balancing veteran that keeps winning raw-throughput benchmarks even when nobody asked it to. This guide lines up all three against the specs, the pricing, the benchmarks, and the migration math you actually need before touching a production cluster.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Kubernetes Ingress Is Suddenly a Live Decision Again
For years, “which ingress controller should I use” had a boring default answer: Ingress-NGINX, the controller living under the kubernetes/ingress-nginx GitHub repository. It shipped with most tutorials, most Helm charts assumed it existed, and most platform teams installed it without a second thought. That changed when Kubernetes SIG Network published its retirement notice in November 2025, citing a thin pool of maintainers and the security risk of running unmaintained code at the edge of a cluster.
The retirement became final on March 24, 2026. Existing Ingress-NGINX installations keep running, and the Helm charts and container images already published stay downloadable. What stops is everything forward-looking: no new CVE fixes, no compatibility updates for newer Kubernetes releases, no roadmap. A project that Kubernetes’ own blog described as powering roughly half of cloud-native environments effectively became a ticking clock for anyone still depending on it.
Kubernetes did not anoint a single successor. Its own guidance points toward the Gateway API as the long-term strategic direction, alongside a plain recommendation to pick “another actively maintained ingress controller” in the meantime. A planned community project called InGate, floated as a possible like-for-like replacement, never got far enough to matter and was retired alongside its parent. To soften the landing, the project shipped Ingress2Gateway 1.0 in March 2026, a tool that translates existing Ingress manifests and controller-specific annotations into Gateway API resources rather than acting as a controller itself.
That leaves teams choosing between three practical paths: adopt Traefik, which has spent the months since the announcement explicitly courting Ingress-NGINX refugees; stick with NGINX through F5’s actively maintained commercial controller, a different codebase from the one that was retired; or move to HAProxy, which has quietly run some of the internet’s highest-traffic load balancing for over two decades. None of this is theoretical anymore. It is the live, unavoidable decision facing any team still running clusters built on the old default.
How We Got Here: A Timeline of the Ingress-NGINX Retirement
The speed of this transition surprised a lot of platform teams, so it is worth laying out exactly how it unfolded. Kubernetes SIG Network and the project’s Security Response Committee first went public with their intent to retire Ingress-NGINX on November 11, 2025, framing it explicitly as a security decision rather than a technical one: the project simply did not have enough active maintainers to keep shipping safe code for a component that sits directly on the network edge of production clusters. The announcement promised best-effort maintenance through March 2026, giving the ecosystem a roughly four-month runway.
The timing collided with an already busy release calendar; teams juggling the Kubernetes 1.37 upgrade on top of an ingress migration had little breathing room. In January 2026, the Kubernetes Steering Committee published a follow-up statement reiterating the timeline and acknowledging that Ingress-NGINX had been, by its own description, critical infrastructure for about half of cloud-native environments. That statement also closed the door on hopes that a successor project called InGate would step in as a seamless continuation; the effort had not matured enough to take over and was wound down alongside the retirement. By late February 2026, Kubernetes published a “before you migrate” post warning teams about several Ingress-NGINX behaviors that do not translate cleanly to other controllers, a tacit admission that this would not be a copy-paste migration for anyone. The retirement became official and final on March 24, 2026, and the Ingress2Gateway 1.0 migration tool shipped within days of that deadline to give teams at least a semi-automated path toward Gateway API.
Traefik vs NGINX vs HAProxy: Full Specs Comparison
Before getting into benchmarks and pricing, it helps to see the three projects side by side on the technical fundamentals. Star counts and release dates below were pulled directly from each project’s public GitHub repository and official documentation as of October 2, 2026.
| Attribute | Traefik | NGINX (F5 Ingress Controller) | HAProxy |
|---|---|---|---|
| Maintainer | Traefik Labs | F5 Inc. | HAProxy Technologies |
| Core language | Go | C | C |
| Latest stable release | Traefik Proxy 3.7.13 (patch of the 3.7 “Langres” line, released May 5, 2026) | NGINX Open Source + nginx/kubernetes-ingress controller (actively maintained, separate from retired Ingress-NGINX) | HAProxy 3.4.0, announced June 3, 2026 |
| License | MIT (open source) | NGINX core: BSD-2-Clause-style license; nginx/kubernetes-ingress repo: Apache License 2.0; NGINX Plus: commercial subscription | GPL v2 (core); HAProxy Enterprise is a separate commercial product |
| GitHub stars (core repo) | 65,049 | 31,780 (nginx/nginx); 5,081 (nginx/kubernetes-ingress) | 6,900 |
| Config reload model | Dynamic, no reload required for most changes | Reload required for config changes (reload time varies by cluster size) | Reload required, though newer versions support seamless reloads |
| Kubernetes Gateway API support | Full support since early implementation; Traefik 3.7 supports Gateway API v1.5.1 | Supported via F5 NGINX Gateway Fabric, a separate Gateway API implementation | Supported via HAProxy Kubernetes Ingress Controller’s Gateway API mode |
| Ingress-NGINX annotation compatibility | 80+ annotations supported natively as of Traefik Proxy 3.7, marketed as a drop-in migration path | N/A — different annotation set entirely, requires manual rewrite | N/A — requires manual rewrite of routing rules |
| Built-in dashboard | Yes, web UI included | Limited; relies on NGINX Plus dashboard for commercial tier | Yes, HAProxy stats page / Data Plane API |
| Let’s Encrypt / ACME automation | Built-in, native support | Requires cert-manager or external tooling | Requires cert-manager or external tooling |
| Service mesh integration | Native Traefik Mesh (lightweight) | Pairs with external mesh (Istio, Linkerd) | Pairs with external mesh; HAProxy also used as mesh data plane in some setups |
| WAF / API gateway add-ons | Traefik Hub adds AI Gateway, MCP Gateway, and a hardened “Distro Zero” image | F5 WAF and API Gateway available as paid add-ons | HAProxy Enterprise bundles OWASP CRS v4-based WAF; HAProxy ALOHA offers hardware/virtual appliance options |
| Multi-cluster / API federation | Traefik Labs added multi-cluster API federation and agent-aware AI controls to its Ingress-NGINX replacement GA in March 2026 | Available via F5 Distributed Cloud, a separate paid product | Available via HAProxy Enterprise clustering features |
Two things jump out from that table. First, Traefik’s entire 2026 strategy is built around being the easiest possible landing spot for Ingress-NGINX refugees: the 80+ annotation compatibility layer and the dynamic no-reload config model exist specifically to reduce migration friction. Second, NGINX and HAProxy both require teams to actually rewrite their ingress rules rather than port them, because neither project shares an annotation dialect with the retired controller.
Benchmark Data: What the Performance Numbers Actually Show
This is where the comparison gets messy, and it is worth being upfront about that rather than pretending there is a clean winner. Independent, reproducible, apples-to-apples benchmarks comparing Traefik, NGINX, and HAProxy as Kubernetes ingress controllers are rare. Most of the numbers circulating online come from either vendor-published tests, which tend to favor the vendor publishing them, or community blog posts that do not fully document their hardware, request patterns, or software versions. With that caveat in place, here is what multiple sources actually reported in 2025 and 2026.
| Source | Traefik | NGINX / Ingress-NGINX | HAProxy | Notes |
|---|---|---|---|---|
| HAProxy Technologies’ own Kubernetes ingress benchmark | Behind HAProxy and Envoy | Trailed the field; config was reportedly throughput-limited | Roughly 2x the throughput of the next competitor, lowest CPU usage and lowest latency across percentiles | Vendor-published; HAProxy tested its own product against four rivals |
| Community Kubernetes load-balancer guide, dev.to, May 2026 | ~19,000 RPS at ~45% CPU, most consistent under bursty load | ~35,000 RPS at ~65% CPU | ~42,000 RPS at ~50% CPU | Independent but methodology not fully published |
| ComputingForGeeks reverse-proxy benchmark, March 2026 | Not included in this test | 60,382 HTTP req/s, 53,162 HTTPS req/s | 57,164 HTTP req/s, 51,298 HTTPS req/s | Independent blog; tested general reverse-proxy mode, not Kubernetes ingress specifically |
| NetworkersHome Kubernetes ingress lab, December 2025 | 9,763 req/s, 3.8ms p99 latency | 9,847 req/s, 4.2ms p99 latency | Not included in this test | Small-scale lab test with 50 Ingress resources and TLS termination |
| Toolradar Traefik vs NGINX comparison, 2026 | ~74,000 RPS | ~100,000 RPS | Not included in this test | Vendor-neutral comparison site, methodology not fully disclosed |
Notice the spread: the same two products show throughput figures ranging from roughly 9,800 requests per second in one test to over 74,000 in another. That is not a contradiction so much as proof that test configuration dominates the result. Payload size, TLS termination settings, the number of routing rules, and whether the benchmark measures cold reloads or steady-state traffic can all swing numbers by an order of magnitude. The one pattern that holds across nearly every source is directional: HAProxy tends to win raw-throughput and CPU-efficiency tests, NGINX sits close behind it, and Traefik trades some raw throughput for operational simplicity, built-in automation, and a reload model that does not interrupt live connections. Reintech’s 2026 ingress controller comparison put it plainly: HAProxy edges out the competition in raw throughput, but NGINX isn’t far behind, while Traefik’s overhead means more pods are needed to handle identical load. Treat every number in that table as a starting point for your own load test, not a verdict.
Pricing Comparison: Open Source vs Enterprise Tiers
All three projects are free at their open-source core, and all three vendors make real money selling support, security add-ons, and multi-cluster management on top. None of the three currently publish exact enterprise pricing on their websites, which is itself useful information for budget planning: expect a sales conversation, not a self-serve checkout, once you move past the free tier.
| Tier | Traefik | NGINX | HAProxy |
|---|---|---|---|
| Open-source core | Free, MIT license, full ingress controller functionality | Free, NGINX Open Source + free nginx/kubernetes-ingress controller | Free, GPL v2, full load-balancer functionality |
| Commercial product name | Traefik Hub (formerly sold as Traefik Enterprise) | NGINX Plus / F5 NGINX Ingress Controller (subscription, JWT-licensed) | HAProxy Enterprise / HAProxy ALOHA (hardware and virtual appliance) |
| Published starting price | Not publicly listed; site shows “Get pricing” with a free trial | Not publicly listed; requires an active F5 subscription and JWT credential | Not publicly listed; HAProxy Technologies directs buyers to contact sales for custom pricing |
| What the paid tier adds | AI Gateway and MCP Gateway add-ons, a hardened “Distro Zero” image, multi-cluster API federation, managed subscriptions | F5 WAF, API Gateway add-ons, F5 Distributed Cloud integration, enterprise support SLAs | OWASP CRS v4-based WAF, 24×7 support, three years of version support per release, ALOHA hardware/virtual appliances |
| Free trial available | Yes | Limited trial licenses available through F5 | Contact sales for trial/proof-of-concept |
For teams on a budget, the practical calculus is simple: the open-source core of all three products handles the vast majority of ingress workloads without licensing cost. The enterprise tiers earn their keep when you need centralized multi-cluster management, a bundled WAF instead of a separately deployed one, or a support contract with guaranteed response times. If none of those apply to you yet, start on the free tier of whichever controller fits your routing-rule complexity and revisit the commercial tier once you are running dozens of clusters rather than a handful.
Licensing: Why It Matters More Than It Used To
Licensing used to be a footnote in infrastructure decisions. After HashiCorp’s Business Source License shift on Terraform rattled the infrastructure-as-code world, platform teams started reading license files before adopting anything load-bearing. The good news here: none of the three ingress options carry that risk.
Traefik ships under the MIT license, among the most permissive licenses in common use, with no restrictions on commercial use, modification, or redistribution. HAProxy’s core is GPL v2, which is also fully open source though it carries copyleft obligations if you modify and redistribute the binary itself (running it as-is in your own infrastructure carries no such obligation). NGINX’s open-source core uses a BSD-2-Clause-style license, and F5’s nginx/kubernetes-ingress controller repository is Apache License 2.0. The commercial tiers, NGINX Plus and HAProxy Enterprise, are proprietary products layered on top of those open-source cores, not relicensed versions of the open-source project. In other words, nobody picking between these three in 2026 needs to worry about a surprise license change pulling the rug out from under a production deployment.
Security Posture: What an Unmaintained Controller Actually Costs You
The sharpest argument for migrating off Ingress-NGINX quickly has nothing to do with features or throughput. It is about who patches the next vulnerability. Every piece of internet-facing software accumulates security findings over time, and ingress controllers are a particularly attractive target because they terminate TLS, parse untrusted HTTP traffic, and often run with elevated cluster permissions. Historically, when a CVE surfaced against Ingress-NGINX, the project’s maintainers triaged it, shipped a patched release, and the ecosystem moved on within days. That pipeline no longer exists. Any vulnerability discovered against the retired controller from this point forward will sit unpatched indefinitely, visible to anyone who checks the public CVE record, with no vendor or community commitment to fix it.
This is precisely why all three replacement options actively publish and patch their own advisories. Traefik Labs maintains a public security advisories feed directly on GitHub, giving platform teams a transparent record of what has been found and fixed. F5 handles NGINX-related disclosures through its standard enterprise security bulletin process tied to active subscriptions, and HAProxy Technologies does the same for HAProxy Enterprise customers while the open-source project tracks issues through the standard CVE/MITRE system. None of the three is immune to vulnerabilities, and new CVEs will surface against all of them over time, the same as any actively maintained networking software. The difference that matters is simple: a patch will actually ship. For a security team doing a risk assessment, “actively patched with an unknown number of future CVEs” beats “frozen with a known, growing, and permanently unpatched attack surface” every time, which is exactly the framing Kubernetes used in its own retirement and migration guidance.
Observability and Monitoring: Getting Visibility Into Your Ingress Layer
Whichever controller you land on, you will want the same visibility you had before: request rates, error rates, latency percentiles, and TLS certificate status, ideally flowing into whatever observability stack your team already runs. All three projects treat this as table stakes, but the depth of built-in tooling differs.
Traefik exposes native metrics in Prometheus, Datadog, StatsD, and OpenTelemetry formats out of the box, alongside distributed tracing support and the built-in dashboard mentioned earlier, which gives operators a live view of routers, services, and middleware without standing up a separate Grafana panel first. NGINX’s open-source core exposes a basic status module, while the commercial NGINX Plus tier adds a much richer live activity monitoring dashboard and deeper Prometheus integration through F5’s broader observability tooling. HAProxy ships a built-in stats page and a Data Plane API that both expose detailed per-backend metrics, and HAProxy Enterprise layers on centralized multi-node reporting for teams running fleets of load balancers rather than a single cluster’s worth. For teams whose top priority is getting a working Grafana dashboard up in an afternoon with minimal glue code, Traefik’s batteries-included approach to observability is the most immediately productive of the three; for teams that already run a mature Prometheus and Grafana stack with custom scraping rules, all three will get the job done equally well once configured.
Gateway API: The Direction Kubernetes Actually Wants You To Go
It is worth separating two different questions that often get conflated: which ingress controller should you run, and which API should your routing rules be written against. Kubernetes’ Ingress API, the one that defines the familiar Ingress resource, is not going anywhere and was not part of the retirement. But Kubernetes’ own guidance is clear that the Gateway API is the modern, more expressive successor, and it has been generally available since Gateway API v1.4.0 shipped in October 2025.
Gateway API gives you role-oriented resources (GatewayClass, Gateway, HTTPRoute) instead of the single flat Ingress object, which maps much more cleanly onto how large organizations actually split responsibility between infrastructure teams and application teams. Traefik was among the earliest controllers to ship full Gateway API v1.4 support and has carried that lead into v1.5.1 support with Traefik Proxy 3.7. NGINX has its own Gateway API implementation in the form of F5 NGINX Gateway Fabric, a separate project from both the retired Ingress-NGINX controller and the commercial NGINX Ingress Controller. HAProxy’s Kubernetes Ingress Controller also ships a Gateway API mode. The Kubernetes project released Ingress2Gateway 1.0 in March 2026 specifically to help teams translate existing Ingress manifests, annotations included, into Gateway API resources rather than hand-rewriting everything.
The practical takeaway: if you are migrating anyway because of the Ingress-NGINX retirement, this is the moment to evaluate whether you should land on Gateway API directly rather than migrating onto a new controller’s flavor of the old Ingress API, only to redo the work again in a couple of years.
Real-World Scenarios: Which Controller Fits Which Team
Specs and benchmarks only tell half the story. Here is how the decision plays out across five common situations platform teams are facing right now.
Scenario 1: A mid-size SaaS company still running the retired controller
A platform team with 40 microservices and dozens of existing Ingress manifests full of nginx.ingress.kubernetes.io annotations is the textbook case for Traefik. The 80+ annotation compatibility layer in Traefik Proxy 3.7 exists precisely to let this kind of team keep most of its YAML untouched during the cutover, buying time to plan a cleaner Gateway API migration later rather than doing both at once under deadline pressure.
Scenario 2: A high-frequency trading or ad-tech platform chasing every microsecond
When raw throughput and the lowest possible CPU overhead per request matter more than developer convenience, HAProxy’s track record of winning independent and vendor benchmarks alike makes it the default starting point for evaluation, especially with HAProxy Enterprise’s clustering features for scaling beyond a single node.
Scenario 3: An enterprise already standardized on F5 for application delivery
Organizations with existing F5 BIG-IP deployments, support contracts, and operational familiarity have a strong case for staying inside the F5 ecosystem via the actively maintained NGINX Ingress Controller rather than introducing a second vendor relationship purely because the old community controller retired.
Scenario 4: A startup that wants zero-downtime config changes without babysitting reloads
Teams deploying dozens of times a day benefit from Traefik’s dynamic configuration model, which avoids the reload-induced latency spikes that both NGINX and HAProxy can exhibit under frequent config churn, plus built-in Let’s Encrypt automation that removes a whole category of cert-manager configuration.
Scenario 5: A platform team building a Gateway API-first multi-tenant cluster from scratch
This is especially common on lightweight distributions; teams comparing K3s, full Kubernetes, and MicroK8s for a new cluster are usually starting from zero ingress configuration anyway. Greenfield clusters with no legacy Ingress-NGINX annotations to carry forward are the ideal case for skipping the Ingress API entirely. Any of the three controllers’ Gateway API implementations can work here, but Traefik’s early and complete Gateway API v1.5.1 support gives it a maturity edge for teams building role-based routing between infrastructure and application teams from day one.
Community and Ecosystem Momentum
GitHub activity is not a perfect proxy for which tool to trust in production, but it is a reasonable signal for where developer attention and third-party tooling investment are concentrated. As of October 2, 2026, Traefik’s core repository sits at 65,049 stars, more than three times HAProxy’s 6,900 and roughly double the combined 36,861 across NGINX’s own core repository and F5’s actively maintained Kubernetes ingress controller repository. The retired kubernetes/ingress-nginx project itself still shows 19,458 stars, a reminder of how large its installed base was even as the project wound down. On the newer Gateway API side, the official kubernetes-sigs/gateway-api repository has crossed 3,014 stars and Envoy Gateway sits close behind at 3,065, both still a fraction of the three incumbent ingress projects’ size but growing as more teams treat Gateway API as the default rather than the adventurous choice.
That gap matters in practical terms. A larger, more active GitHub community tends to translate into faster answers on Stack Overflow and Kubernetes Slack channels, a wider selection of community Helm chart variations, and more third-party blog posts documenting edge cases you are likely to hit. Traefik Labs has also been explicit in its own public materials about using this moment strategically, positioning its March 2026 GA release of Ingress-NGINX compatibility features as, in the company’s own words, the point at which it became “the de facto standard for Kubernetes networking” as platform vendors migrated away from the retired controller. That is a vendor’s own characterization of its market position, not an independent verification, but the underlying GitHub numbers and release cadence support the broader claim that Traefik has captured a disproportionate share of the migration traffic so far.
Migration Guide: Moving Off the Retired Ingress-NGINX Controller
Whichever target you pick, the mechanics of leaving Ingress-NGINX follow a similar sequence. Here is the practical path.
Step 1: Inventory what you actually have. Export every Ingress resource and catalog which nginx.ingress.kubernetes.io annotations are in active use. Rewrite rules, rate limiting, custom headers, and auth snippets are the ones most likely to need manual translation regardless of target.
Step 2: Decide between Ingress API and Gateway API. If you are migrating under time pressure, staying on the Ingress API with a new controller is faster. If you have runway, moving straight to Gateway API avoids a second migration later. Kubernetes’ own Ingress2Gateway 1.0 tool can automate much of this translation.
Step 3: Stand up the new controller in parallel. Deploy Traefik, NGINX, or HAProxy’s ingress controller alongside the existing Ingress-NGINX installation rather than replacing it in place. Use a separate IngressClass or a canary subset of hostnames to validate behavior before cutting over traffic.
# Example: install Traefik via Helm alongside an existing Ingress-NGINX deployment
helm repo add traefik https://traefik.github.io/charts
helm repo update
helm install traefik traefik/traefik \
--namespace traefik --create-namespace \
--set ingressClass.enabled=true \
--set ingressClass.isDefaultClass=false
Step 4: Migrate annotations and test against a non-production hostname. If moving to Traefik, review which of the 80+ supported Ingress-NGINX annotations map directly and which need a Traefik Middleware resource instead. If moving to NGINX or HAProxy, expect to hand-translate rewrite and auth rules since neither shares an annotation dialect with the retired controller.
Step 5: Cut over DNS or load balancer traffic gradually. Shift a small percentage of hostnames first, watch error rates and latency percentiles, then expand. Keep the old Ingress-NGINX deployment running in a frozen, read-only state as a rollback path until the new controller has handled a full traffic cycle, including any weekly batch jobs or peak-traffic events, without incident.
Step 6: Decommission Ingress-NGINX. Once every hostname is confirmed migrated and monitoring shows a clean bill of health, remove the old controller, its ClusterRole bindings, and any leftover CRDs. Because the project will never receive another security patch, leaving it installed anywhere in the cluster, even unused, is an unnecessary attack surface. The same housekeeping discipline applies to the TLS secrets and certificates your ingress layer depends on; if you have not already standardized how those are issued and rotated, it is worth reviewing how External Secrets Operator, Sealed Secrets, and Vault compare before you wire a new controller into production.
Pros and Cons: Traefik
Pros: Purpose-built migration path from Ingress-NGINX with 80+ supported annotations; dynamic configuration with no reload downtime; native Let’s Encrypt automation; full Gateway API v1.5.1 support; permissive MIT license; built-in dashboard and strong Kubernetes-native ergonomics; active vendor investment specifically targeting this migration wave.
Cons: Trails HAProxy and often NGINX on raw throughput benchmarks; higher memory footprint per request in some independent tests; enterprise tier (Traefik Hub) pricing is not public, requiring a sales conversation; smaller footprint in large, change-averse enterprises compared to NGINX’s install base.
Pros and Cons: NGINX
Pros: Enormous existing install base and operator familiarity; backed by F5 with enterprise support and a separate, actively maintained Ingress Controller unaffected by the community project’s retirement; competitive throughput in independent benchmarks; mature WAF and API gateway add-ons through F5’s broader product line.
Cons: No direct annotation compatibility with the retired Ingress-NGINX controller despite the shared name, creating real migration work rather than a drop-in swap; config reloads required for most changes; commercial tier requires an active subscription and JWT licensing rather than a published self-serve price; potential for confusion between the retired community project and the actively maintained commercial one.
Pros and Cons: HAProxy
Pros: Consistently strong raw-throughput and low-CPU performance across multiple benchmark sources; mature, battle-tested codebase with decades of production use outside Kubernetes too; GPL v2 open-source core with a clear commercial upgrade path; HAProxy ALOHA offers hardware appliance options for teams that want load balancing off the Kubernetes control plane entirely.
Cons: Smaller Kubernetes-native ecosystem and fewer built-in automations (Let’s Encrypt, dashboards) compared to Traefik out of the box; steeper configuration learning curve for teams without prior HAProxy experience; enterprise pricing is entirely quote-based with no published starting point; less marketing and community momentum around Kubernetes-specific use cases compared to Traefik’s current migration push.
Who Should Choose What: 5+ Use-Case Recommendations
Pulling the scenarios and trade-offs together into direct recommendations:
- Choose Traefik if you are migrating off the retired Ingress-NGINX controller under time pressure and want the lowest-friction path, or if you deploy frequently and need zero-downtime config changes.
- Choose Traefik if you want Gateway API support that is already mature rather than newly bolted on, or if you want built-in AI/MCP gateway capabilities without assembling them from separate tools.
- Choose NGINX if your organization already has an F5 relationship, support contract, or BIG-IP deployment and wants to consolidate vendor relationships rather than add a new one.
- Choose NGINX if your team’s operational runbooks, monitoring, and institutional knowledge are already built around NGINX’s configuration model and you want to preserve that investment.
- Choose HAProxy if your workload is latency- or throughput-sensitive enough that the benchmark gaps described above would materially affect your infrastructure costs or user experience.
- Choose HAProxy if you want the option to run the same load-balancing technology both inside and outside Kubernetes, or need a hardware appliance option via ALOHA for compliance or data-center reasons.
- Choose a Gateway API-first approach with any of the three if you are building a new multi-tenant cluster from scratch and have no legacy Ingress-NGINX annotations to carry forward.
The Verdict: Which One Should You Actually Run
There is no single correct answer here, and anyone telling you otherwise is skipping past real trade-offs. But the data points toward a reasonably clear default. For the large majority of teams whose main problem is “we have to leave the retired Ingress-NGINX controller and we don’t want a second migration project next year,” Traefik is the most direct path: Traefik Proxy 3.7’s 80+ annotation compatibility layer, its dynamic no-reload config model, and its mature Gateway API v1.5.1 support were built specifically to absorb this exact migration wave, and the vendor’s own GitHub star count, 65,049 as of October 2026, more than three times HAProxy’s and roughly double NGINX’s core repo, reflects how much of the community has already voted with its deployments.
That said, the benchmark data is honest enough to say Traefik is not the fastest option on the table. If your workload lives or dies on shaving milliseconds off p99 latency at extreme request volumes, HAProxy’s consistent lead in both vendor and independent throughput tests makes it worth the steeper configuration curve. And if your organization already has deep F5 investment, there is little reason to introduce a second vendor relationship purely because a differently-named, differently-maintained project reached end of life. The retirement of Ingress-NGINX was a forcing function, not a verdict on any of the three replacements. Use it as the excuse to finally benchmark your own traffic patterns against all three before you commit a production cluster to any of them.
Frequently Asked Questions
Is Ingress-NGINX completely dead, or can I still use it?
The community-maintained Ingress-NGINX controller was officially retired on March 24, 2026. Existing installations, Helm charts, and container images continue to work and remain available, but the project will not receive any further releases, bug fixes, or security patches. Running it in production going forward means running unmaintained, unpatched code at your cluster’s edge indefinitely.
Is F5’s NGINX Ingress Controller the same project that got retired?
No. The retired project is the community-maintained kubernetes/ingress-nginx controller. F5’s nginx/kubernetes-ingress controller is a separate codebase that remains actively maintained and is unaffected by the retirement, though it uses different configuration annotations than the retired controller.
Does Traefik really support my existing Ingress-NGINX annotations?
Traefik Proxy 3.7, released in May 2026, added support for more than 80 Ingress-NGINX annotations specifically to ease this migration. Coverage is broad but not complete, so plan to test your specific annotation set, particularly custom rewrite rules and auth snippets, before a full cutover.
Should I migrate straight to Gateway API instead of choosing a new Ingress controller?
If you have the engineering time, yes. Gateway API has been generally available since v1.4.0 in October 2025 and is the direction Kubernetes officially recommends. All three controllers covered here support it, with Traefik having the most mature implementation as of its 3.7 release. Kubernetes’ Ingress2Gateway 1.0 tool can help automate the translation from existing Ingress manifests.
Which of the three is fastest?
Published benchmarks disagree sharply on exact numbers, but most sources, including HAProxy Technologies’ own tests and several independent community benchmarks, show HAProxy leading on raw throughput and CPU efficiency, with NGINX close behind and Traefik trading some throughput for operational simplicity and zero-downtime config reloads. Run your own load test against your actual traffic pattern before trusting any published figure.
Do any of these three have licensing risk like Terraform’s Business Source License change?
No. Traefik is MIT licensed, HAProxy’s core is GPL v2, and NGINX’s open-source core uses a BSD-2-Clause-style license, with the nginx/kubernetes-ingress repository under Apache 2.0. All three are stable, fully open-source licenses with no pending or historical relicensing event affecting their core projects.
How much does the enterprise tier of each product cost?
None of the three vendors publish exact enterprise pricing. Traefik Hub, NGINX Plus/F5 NGINX Ingress Controller, and HAProxy Enterprise all require contacting sales for a custom quote. Budget for a sales cycle rather than a self-serve checkout if you need the commercial tier.
What happens if I do nothing and keep running the retired Ingress-NGINX controller?
Your cluster keeps functioning in the short term, but you accumulate unpatched security risk with every month that passes, since no CVE fixes will ever be released for the project again. Kubernetes’ own migration guidance explicitly warns against treating this as a long-term option given the controller’s privileged position at the cluster’s network edge.
