Platform Monkey ctx

Ingress NGINX: The Default Front Door of Kubernetes, Retired by the People Who Kept It Alive

2015–2026 (archived) · · By

Born as a sample controller inside the kubernetes/contrib repo, Ingress NGINX became the default traffic entry point for half the cloud-native world — then was archived after years of one-maintainer heroics.

Sources

Somewhere in your infrastructure right now, a controller is happily proxying traffic through an NGINX config nobody has updated in years. That's the Ingress NGINX story in one sentence: software so reliable that half the cloud-native world forgot it was maintained by one or two people in their spare time — until , when the Kubernetes project archived the repository and the forgetting stopped being free. This is the tale of the default front door of Kubernetes: built as a demo, adopted by millions, patched through a 9.8-CVSS nightmare, and finally retired not because it stopped working, but because it worked too well for anyone to notice it was dying.

The Origin: A Sample Implementation That Became the Standard

2015 — Ingress the API ships before Ingress the product exists

When Kubernetes 1.1 shipped in , it carried a new beta API object called Ingress: a declarative way to say "route HTTP(S) traffic for these hosts and paths to these services." The API was a spec with no engine — the Kubernetes docs explicitly told users to pick an Ingress controller implementation, and the ecosystem scrambled to build them. The reference implementations lived in kubernetes/contrib, a grab-bag incubator repo for "components in the Kubernetes ecosystem that aren't part of the Kubernetes core" — a repo that would itself be archived years later, a detail that foreshadows this whole tale.

February 8, 2016 — commit 34b949c13, "Godeps"

The oldest commit preserved in the Ingress NGINX history is 34b949c13 — "Godeps", pushed on by Prashanth Balasubramanian (GitHub: bprashanth), a Google engineer working on Kubernetes networking. The commit is nothing but vendored dependencies — a project being born mid-gestation, already behind on its Go vendor tree. In those first months the repo lived under the ingress/ path of kubernetes/contrib, with Manuel de Brito Fontes (GitHub: aledbf, a Chilean engineer who lists the NGINX Ingress Controller as his own creation from October 2015) landing the NGINX-specific machinery: Prometheus metrics, health checks, DaemonSet support, and the first raw-config annotations that would later become the project's defining feature — and its fatal flaw.

November 4, 2016 — repo split, and a ten-year identity crisis begins

On , Tim Hockin committed "Initial commit" and the controller moved out of contrib into its own home: kubernetes/ingress-nginx. The first PR, #1 "Basic structure", was bprashanth's, merged November 10. At the same time, the company NGINX, Inc. was building its own controller in a repo named nginxinc/kubernetes-ingress (created March 2016). From day one the ecosystem carried two confusingly named NGINX ingress controllers — community ingress-nginx versus vendor nginx-ingress — a naming trap that would still be biting buyers in 2026, after F5's $670M acquisition of NGINX in March 2019 made the vendor one an F5 product line. The community one, free and cloud-agnostic, won the adoption war decisively — 19,468 stars against the F5 controller's ~5,077 at archive time — but the names remain a landmine: "nginx ingress" today means an actively maintained F5 product; "ingress nginx" means an archived community project. Order matters.

The Timeline: From Contrib to Core to Archived

Crisis Points: What Actually Killed It

1. The snippet flexibility (2016–2026, terminal)

The feature that made Ingress NGINX ubiquitous was raw escape hatches: annotations like configuration-snippet and server-snippet that let any Ingress author inject arbitrary NGINX directives into the generated config. In 2016 that was pragmatism — the Ingress API couldn't express half of what NGINX could do, so the controller let you escape the API. By 2025 the Kubernetes project's own retirement post called it what it had become: "Yesterday's flexibility has become today's insurmountable technical debt." Arbitrary config injection is, by definition, a configuration-injection attack surface — IngressNightmare's RCE chains went through exactly that machinery in the admission webhook. The architectural sin was committed in year one; the CVE was just the receipt.

2. The maintainer arithmetic (2021–2026, terminal)

Every public statement from the project says the same thing in different words: for years, one or two people did the development work, on their own time, after hours and on weekends. The contributor numbers are stark — aledbf: 2,501 commits, more than the next three humans combined; the top non-bot, non-lead contributors (Gacko at 449, ElvinEfendi at 219, rikatz at 178, bprashanth at 163) mostly rotated to other projects. The creator stepped back to emeritus in 2021. The wind-down announcement in issue #13002 explicitly begged for help and got none at the required scale. Tim Hockin's summary is the harshest fact in this tale: "In the two years this has been a topic, almost nobody has stepped up. There are no new maintainers in the pipeline."

aledbf      Manuel de Brito Fontes   2501   (creator; emeritus since 2021)
Gacko       Marco Ebert              449   (last active maintainer)
ElvinEfendi Elvin Efendi             219
rikatz      Ricardo Katz             178
bprashanth  Prashanth B.             163   (founder, kubernetes/contrib era)
longwuyuan  Long Wu Yuan             117

Compare the corporate footprint: F5 — the company that owns NGINX itself — employs engineers on its own controller (nginx/kubernetes-ingress, actively maintained) but never staffed the community one that had four times its adoption. The company with the most direct commercial stake in "NGINX + Kubernetes" spent seven years letting volunteers carry the version everyone actually used.

3. InGate — the successor that wasn't (2024–2026)

The maintainers' 2024 plan was honest and reasonable: stop adding features, build InGate as an Ingress-plus-Gateway-API controller with the Gateway API community, then put ingress-nginx into formal maintenance mode. The InGate repo was created on , and the retirement post's verdict two years later is one of the most quietly devastating sentences the Kubernetes project has published: "InGate development never progressed far enough to create a mature replacement; it will also be retired." The repo now lives under kubernetes-retired with 719 stars and an EOL notice. Both the old tool and its designated successor died in the same announcement.

Community Engine & Corporate Influence: Who Actually Built It

The money question for any infrastructure tale: who paid? In Ingress NGINX's case the honest answer is nobody, structurally — and that is precisely the point the retirement makes. The founding engineers came through Google (bprashanth) and the early Kubernetes networking circle (aledbf, ElvinEfendi); later maintainers arrived from the user side — Marco Ebert in the Helm-chart trenches, Ricardo Katz and James Strong from the security and community angle. No vendor ever owned it, which was the adoption superpower: every cloud, every distro, every homelab could ship it without asking a competitor for permission. Kubernetes itself does not distribute it, so it never sat in a CNCF maturity level with the foundation's institutional support either — it lived in the kubernetes/ GitHub org on SIG Network's volunteer bench.

The corporate influence story is mostly about absence. F5 bought NGINX and invested in its own parallel controller. The hyperscalers bundled ingress-nginx into managed offerings (AKS's Application Routing add-on is an NGINX-based controller) but staffed their own alternatives — Azure Application Gateway for Containers, GKE Gateway — rather than the community project. Datadog, whose internal research says ~50% of cloud-native environments run the thing, contributed its co-chair of Kubernetes SIG Security (Tabitha Sable) to the retirement communication rather than maintainers to the code. The one company that did step up did so after the death sentence, commercially: Chainguard now maintains the EmeritOSS fork — free in source form on GitHub, with hardened CVE-free images as the commercial upsell. Rogers Communications, quoted in Chainguard's announcement, said out loud what most platform teams were thinking: a supported ingress-nginx "allows us to spend more time to evaluate the plan to move teams to another ingress controller or gateway API."

The successor standard, Gateway API, is where the community's networking engineering effort now actually lives — v1.6.0 in June 2026 (TCPRoute and UDPRoute to standard), v1.6.2 by September, with conformant implementations from Envoy Gateway, Istio, Cilium, Traefik, HAProxy's Unified Gateway, F5's own NGINX Gateway Fabric, and cloud providers. The lesson the ecosystem extracted: adoption without contribution is not sustainability, and "the default" is a role someone has to be paid to hold.

Current Trajectory: The Verdict

Who should still care: any team running the archived controller in 2026 owes itself one afternoon — the detection command is kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx — followed by an honest inventory of which annotations actually made it into your manifests. Teams that never left the basic host/path/TLS feature set will find the Gateway API migration cheap; teams with snippet-laden legacy configs have found the hardest part of the migration is not the tooling but discovering what their Ingress objects actually do.

Final verdict: Ingress NGINX is the purest specimen in the OSS graveyard of a success-theory failure: it won adoption completely, monetized nothing, staffed itself on evenings and weekends, and was retired by the same volunteer structure that built it — politely, publicly, and with a four-month warning the community roundly declared insufficient. The Kubernetes project's decision was correct and the maintainer burnout was real; so was the ecosystem's decade of free-riding on two people's spare time. The front door of half the cloud-native world is now a read-only repository, a security-maintained fork with a commercial upsell, and a migration CLI shipped the same week the door closed. Everything about how your cluster receives traffic in 2026 traces back to what this project normalized — and everything about how open-source infrastructure dies traces back to what it never solved.