Na última edição da KubeCon North America, realizada em Atlanta, os holofotes estavam voltados para novos anúncios, tendências em automação e o futuro do Kubernetes. Mas, longe dos palcos principais, uma das notícias mais importantes e preocupantes passou quase despercebida: o Ingress NGINX Controller será oficialmente aposentado em março de 2026.
A partir dessa data, o projeto não receberá mais atualizações, correções de bugs ou patches de segurança. Em termos práticos, torna-se abandonware, mesmo ainda sendo amplamente utilizado por empresas e desenvolvedores ao redor do mundo. Para um componente tão central dentro de milhares de clusters Kubernetes, isso é um alerta sério sobre a forma como o ecossistema open source vem sendo sustentado.
O Ingress NGINX é o controlador de entrada mais popular para Kubernetes. Ele funciona como um proxy reverso responsável por receber tráfego HTTP e HTTPS vindo da internet e encaminhar corretamente as requisições para os serviços internos de um cluster. Com base em regras de domínio, caminhos de URL e certificados TLS, o controlador decide para onde cada solicitação deve ir. Em outras palavras, ele faz a “porta de entrada” de aplicações em produção, exatamente o tipo de componente que não pode falhar.
Por isso, causa estranheza imaginar que um projeto tão disseminado esteja chegando ao fim. Afinal, não estamos falando de um software abandonado sem usuários. Existem milhares de instalações ativas dependendo diretamente dele.
Um problema antigo
O encerramento do Ingress NGINX não aconteceu devido à perda de relevância técnica, mas simplesmente porque o projeto ficou sem braços humanos para sustentá-lo.
Segundo explicou Tabitha Sable, engenheira da Datadog e co-chair do grupo de segurança do Kubernetes, o projeto sofreu com uma escassez crônica de mantenedores durante anos. Normalmente, apenas uma ou duas pessoas realizavam praticamente todo o trabalho de desenvolvimento, revisão de código e manutenção de forma voluntária, no tempo livre, depois do expediente e nos fins de semana.
Em 2024, os mantenedores anunciaram planos para encerrar o desenvolvimento ativo e colaborar com a comunidade do Gateway API na criação de um novo controlador, chamado provisoriamente de InGate. Mesmo assim, o comunicado praticamente não gerou interesse de novos colaboradores para ajudar na migração ou assumir a manutenção do Ingress atual.
A falta de apoio contínuo foi minando qualquer chance de sobrevivência do projeto. Mas o golpe final veio com a descoberta de uma falha de segurança gravíssima.
O último prego no caixão
A empresa de segurança Wiz revelou uma vulnerabilidade considerada crítica no Ingress NGINX. Segundo sua análise, essa falha permitiria a um invasor:
- Executar código arbitrário;
- Acessar segredos armazenados em diferentes namespaces;
- Tomar controle completo do cluster.
Em um ambiente corporativo, isso significa a possibilidade de comprometimento total da infraestrutura — algo inaceitável para qualquer serviço em produção. Para um projeto já à beira do fim e sem corpo de mantenedores capaz de reagir rapidamente, o problema tornou-se a confirmação de que não havia mais como continuar com segurança.
A decisão de aposentadoria foi tomada, mas a comunidade reagiu com indignação.
Em fóruns como o Reddit, usuários destacaram que o prazo de pouco mais de um ano é curto para substituir uma peça fundamental da infraestrutura. Alguns apontaram que só a reescrita de documentações corporativas e ajustes em pipelines pode levar mais tempo do que isso.
Voluntariado versus realidade corporativa
A resposta de Tim Hockin, um dos mantenedores históricos do Kubernetes, foi direta: os desenvolvedores que trabalharam no Ingress NGINX sempre o fizeram de graça, movidos por senso de responsabilidade, não por obrigação contratual. Durante dois anos inteiros, quase ninguém apareceu para dividir o trabalho. Não havia novos mantenedores à vista. Diante disso, manter o projeto vivo tornara-se simplesmente impossível.
E ele está certo, ainda que isso não alivie o impacto para quem depende da ferramenta.
O episódio expõe um problema estrutural: muitos dos projetos open source mais críticos do mundo são sustentados por trabalho voluntário, apesar de gerarem valor direto para empresas multibilionárias.
Não se trata de uma falha isolada.
O mesmo desequilíbrio aparece em outros projetos essenciais, como o FFmpeg, uma biblioteca central para praticamente toda a reprodução e transcodificação de vídeo no planeta. Mesmo sendo parte invisível de plataformas de streaming, navegadores e sistemas de TV, o projeto também sofre com uma avalanche de demandas de segurança e poucas fontes de financiamento estruturado.
Como lembrou William Morgan, CEO da Buoyant (empresa responsável pelo Linkerd):
“A relação da maior parte do ecossistema com o open source é de consumo, não de contribuição.”
Ou seja, muitas empresas utilizam projetos críticos como infraestrutura gratuita, mas não investem diretamente na sua sustentação.
Morgan aponta dois modelos que funcionam:
- Projetos financiados por empresas que vendem diretamente o produto baseado no software (como a Buoyant com o Linkerd);
- Projetos bancados por grandes empresas cujo lucro depende diretamente daquela tecnologia — como o Google com Kubernetes, impulsionando vendas na Google Cloud.
No fim das contas, a solução é simples, e ao mesmo tempo politicamente sensível: Pagar os mantenedores.
O encerramento do Ingress NGINX desmonta a ideia romantizada de que o open source sempre encontrará voluntários dispostos a carregar sozinho sistemas globais complexos. Essa lógica podia funcionar quando os projetos eram pequenos e experimentais. Mas hoje, quando bibliotecas e serviços open source sustentam cadeias industriais inteiras, isso se torna inviável.
Desenvolvedores cansam, envelhecem, precisam pagar contas e cuidar da própria saúde. Voluntariado não deveria sustentar infraestruturas críticas de escala planetária. O que aconteceu com o Ingress NGINX foi menos um acidente e mais uma consequência previsível de um sistema de incentivos falho.
Se empresas que lucram com essas tecnologias não assumirem responsabilidade financeira direta, outros projetos seguirão pelo mesmo caminho, deixando usuários correndo atrás de alternativas sob pressão, exatamente como acontece agora no ecossistema Kubernetes.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!