Stack Overflow Leaves NGINX Ingress: What's Behind It and Should You Follow Suit

When a team with Stack Overflow's traffic volume decides to swap a key infrastructure component, it's always worth a closer look — not so much at the choice itself, but at the reasoning behind it. Ingress-NGINX has been the de facto standard for Kubernetes clusters for years, but the news of its impending end of support made many teams think about a fallback. Stack Overflow went all the way — and chose Envoy Proxy via Envoy Gateway. Their detailed post is less a success story and more an honest breakdown of how much engineering time such a migration costs and what trade-offs are unavoidable.

It's Not That NGINX Is Bad, but the Platform Changed

Important point: Ingress-NGINX isn't dying because it's bad. It's dying because the project, once part of Kubernetes, was effectively pushed out: first moved to a third-party repository, then announced as discontinued. For a team building a long-lived platform, that's a red flag — staying on a project with no future is risky. In our experience, if a component lacks a stable roadmap and active maintainers, you'll eventually have to replace it, and the earlier you realize that, the cheaper the migration.

Stack Overflow didn't wait for support to end — they started migrating early. And that's probably the main lesson: leaving Ingress-NGINX is not a technical problem, it's an organizational one. Their choice of Envoy over, say, Traefik or HAProxy is explained not so much by performance (though Envoy is indeed faster with large rule sets) but by the ecosystem: Envoy Gateway provides a CRD-oriented API that integrates more easily with GitOps and security policies.

The Cost of Migration: Not Just Time, but Culture

The most valuable part of their article is the honest numbers. The migration took months, not weeks. They had to rewrite annotations, adapt monitoring, retrain the team. Envoy Gateway is still a young project, and its documentation isn't as rich as Ingress-NGINX's. Stack Overflow explicitly says they had to rework some internal tools to fit the new configuration model.

We at WIZICO often see the opposite: teams swap Ingress for something "more modern" while underestimating the migration cost. If you have 20 rules and one cluster — the move takes a couple of days. If you have hundreds of services with custom annotations, rate limiting, oAuth proxies, and A/B testing at the Ingress level — be prepared to rewrite half the logic from scratch for Envoy.

Envoy Is Not a Silver Bullet

Envoy is indeed more powerful: it supports L7 load balancing with advanced telemetry, WebSocket, gRPC, and dynamic configuration via xDS. But that power comes at the cost of complexity. Envoy Gateway simplifies things, but not enough for a single person to maintain it without deep understanding of Envoy's networking model. If your team isn't ready to invest in Envoy expertise, it might be wiser to look at alternatives like Traefik (easier to configure) or even stay on Ingress-NGINX until it stops working, then migrate at a relaxed pace.

Stack Overflow is not an ordinary company. They have an engineering culture that allows dedicating a team for six months to replace an Ingress controller. If you don't have that luxury, first assess how critical it is for your business to have the "most modern" Ingress controller rather than just a working one.

The main takeaway we got from this story: the decision to switch Ingress controllers should be driven by specific problems your current controller stops solving, not by the hype around Envoy. And if there are no such problems — maybe the best strategy is not migration, but monitoring and a plan B in case Ingress-NGINX support finally ends.