Ingress-nginx is being retired in March 2026. After analyzing over 1,000 ingress resources across our managed clusters, we’ve landed on a hybrid approach: Traefik as the default replacement, with AWS Load Balancer Controller for environments that benefit from tight AWS integration. Here’s what we learned and how we’re moving forward.
The Announcement That Changed Everything
In November 2025, Kubernetes SIG Network and the Security Response Committee announced the retirement of ingress-nginx. Best-effort maintenance will continue until March 2026. After that: no further releases, no bugfixes, and critically, no security updates.
For many of us, ingress-nginx has been the reliable workhorse of Kubernetes networking. It’s the Swiss Army knife that handles TLS termination, path-based routing, authentication, rate limiting, and dozens of other features through a sprawling collection of annotations. That flexibility powered countless clusters, from homelabs to massive production deployments. But it came at a cost.
What the Kubernetes community called out directly: the breadth and flexibility that made ingress-nginx popular also made it increasingly difficult to maintain. Features that were once considered helpful options—like the ability to inject arbitrary nginx configuration via snippet annotations—came to be seen as serious security risks. Yesterday’s flexibility became today’s technical debt.
Despite its popularity, the project has struggled with maintainership for years. As the announcement noted, development work often fell to just one or two people, working on their own time after hours and on weekends. Plans to build a replacement controller (InGate) never progressed far enough to create a viable alternative. The decision to retire the project was made to prioritize user safety.
Understanding the Scope: 1000+ Ingresses Under the Microscope
When we first heard the news, we needed to understand exactly what we were dealing with. We wrote scripts to analyze every ingress resource across all the Kubernetes clusters we manage, filtering for those using ingress-nginx IngressClasses.
The results were 1097 unique ingress resources using 89 distinct annotation types.
Here’s what the usage distribution looked like for the most common annotations:
This data told us two things. First, TLS and basic routing are universal—every ingress needs them. Second, there’s a long tail of advanced features (CORS, rate limiting, authentication, custom snippets) that significant portions of our customer base depend on.
The custom snippets were particularly concerning. These 56 ingresses contain raw nginx configuration that won’t translate to any other controller. Each one would need manual analysis.
