ingress-nginx: how a small API acquired its own language (Category PlatformEngineering)

Dealing with closing ingress-nginx. This story can be described as an open source drama: the component for about half of cloud-native environments, according to internal data from Datadog, was supported for years by one or two people in their spare time. But I'm more interested in the mechanism that made him unaccompanied.

The Ingress API was deliberately left small: host, path, backend, TLS. Production quickly needed timeouts, repeated attempts, canary, external authorization, headers and WAF. ingress-nginx added all this in annotations - by July 2026 year documentation numbered 130 unique keys. Snippet annotations allowed you to insert arbitrary fragments of NGINX-config.

So the workaround turned into an informal DSL. The API looked simple, but the real contract lived in the strings of metadata, depended on the controller, poorly validated and expanded the attack surface. In 2025 Wiz revealed IngressNightmare is a chain of vulnerabilities with unauthenticated RCE.

In March 2026 year support for ingress-nginx finishedNo more releases, bug fixes and security patches. Existing installations continue to work - just without future fixes. The Ingress API itself is neither closed nor deprecated: it is frozen, and development has gone to the Gateway API.

Gateway API Not necessarily smaller or simpler. It has more explicit resources, roles, connections and policies. But that's the point: the complexity got types, owners and verifiable boundaries instead of hundreds of string exceptions.

If you look at this story from the point of view of API design, you can see that it is important not only to make it minimal, but also to leave the groundwork for controlled expansion and understandable migration routes. If this is not done, people will begin to build a second, hidden language around a minimal API and increase complexity. The first version will be buried under the weight of complexity and the impossibility of expansion and support.

#PlatformEngineering #Kubernetes #Architecture #DevOps #Security