NGINX Community Blog

The Ingress NGINX Alternative: Open Source NGINX Ingress Controller for the Long Term

—

by

Micheál Kingston
in

The Kubernetes community announced that Ingress NGINX will be retired in March 2026. After that, there won’t be any more updates, bugfixes, or security patches. This decision came after years of the project being maintained by just 1-2 developers working nights and weekends, plus some serious security issues earlier this year (IngressNightmare CVE-2025-1974) that made it clear the project needed more resources than it had. 

Your existing deployments will keep working, but running without security updates is risky and there will be no further feature developments. You know all this, of course. That said…. 

Your Options (And Why We Hope You’ll Consider NGINX OSS) 

There are several good Ingress controllers available – Traefik, HAProxy, Kong, Envoy-based options, and Gateway API implementations. The Kubernetes docs list many of them, and they all have their strengths. 

Some of you may know that F5 maintains an OSS permissively licensed NGINX Ingress Controller). (Fun fact — It actually started as an intern project at NGINX, Inc. in 2016, prior to the acquisition by F5.) The project is  open source, Apache 2.0 licensed, and will stay that way. There is a team of dedicated engineers working on it with a slate of upcoming upgrades. If you’re already comfortable with NGINX and just want something that works without a massive learning curve, we believe that the F5 NGINX Ingress Controller for Kubernetes is your smoothest path forward. 

Here’s why we think you’ll actually like it: 

  • Minimal learning curve: Uses the same NGINX engine you already know. Most Ingress NGINX annotations have direct equivalents, and the migration guide provides clear mappings for your existing configurations. 
  • Sustainable maintenance: A dedicated full-time team at F5 ensures regular security updates, bug fixes, and feature development.  
  • Production-tested at scale: Powers approximately 40% of Kubernetes Ingress deployments with over 10 million downloads. It’s battle-tested in real production environments. 
  • Kubernetes-native design: Custom Resource Definitions (VirtualServer, Policy, TransportServer) provide cleaner configuration than annotation overload, with built-in validation to prevent errors. 
  • Advanced capabilities when you need them: Support for canary deployments, A/B testing, traffic splitting, JWT validation, rate limiting, mTLS, and more – available in the open source version. 
  • Future-proof architecture: Active development of NGINX Gateway Fabric provides a clear migration path when you’re ready to move to Gateway API. 
  • Optional commercial backing: While the OSS version is robust, NGINX Plus integration is available for enterprises needing active health checks, dynamic reconfiguration, advanced session persistence, and commercial support. 

Moving to NGINX Ingress Controller 

Here’s a rough migration guide. You can also check our more detailed migration guide on our documentation site.  

Phase 1: Take Stock 

  • See what you have: Document your current Ingress resources, annotations, and ConfigMaps 
  • Check for snippets: Identify any nginx.ingress.kubernetes.io/configuration-snippet annotations  
  • Confirm you’re using it: Run kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 

Phase 2: Translate Your Config 

  • Convert annotations: Most of your existing annotations have equivalents in NGINX Ingress Controller – there’s a comprehensive migration guide that maps them out 
  • Consider VirtualServer resources: These custom resources are cleaner than annotation-heavy Ingress and give you more control, but it’s your choice 
  • Handle edge cases: For anything that doesn’t map directly, you can use snippets or Policy resources 

Phase 3: Test Everything 

  • Try it with test apps: Create some test Ingress rules pointing to NGINX Ingress Controller 
  • Run both side-by-side: Keep both controllers running and route test traffic through the new one 
  • Verify functionality: Check routing, SSL, rate limiting, CORS, auth – whatever you’re using 
  • Check performance: Verify it handles your traffic the way you need 

Phase 4: Move Over Gradually 

  • Start small: Migrate your less critical applications first 
  • Shift traffic slowly: Update DNS/routing bit by bit 
  • Watch closely: Keep an eye on logs and metrics as you go 
  • Keep an escape hatch: Make sure you can roll back if something goes wrong 

Phase 5: Finish Up 

  • Complete the migration: Move your remaining workloads 
  • Clean up the old controller: Uninstall community Ingress NGINX once everything’s moved 
  • Tidy up: Remove old ConfigMaps and resources you don’t need anymore 

Why NGINX Ingress Controller Makes Sense (Some Recap) 

It’s actually open source 

  • Fully open source under Apache 2.0 – you’re not getting locked into something proprietary 
  • All development happens publicly on GitHub 
  • F5 is committed to keeping it open source – it’s core to our business model 
  • This has sustainable backing and investment from F5

It’s familiar territory 

  • Same NGINX engine under the hood that you already know 
  • If you’ve been using Ingress NGINX, you already understand most of what Ingress Controller does 
  • The migration docs show direct mappings for most of your existing config 
  • You’re not learning something completely new 

It’s actively maintained 

  • Dedicated full-time engineers at F5 NGINX
  • Regular updates and security patches 
  • About 40% of Kubernetes deployments use it, so it’s well-tested 
  • If you need it, commercial support is available (though the OSS version is solid) 

Help today with a path to tomorrow 

  • If you need to move to a commercial version, we can help translate annotations and other customizations over to NGINX 
  • The NGINX team also has a Gateway API implementation – NGINX Gateway Fabric –  when you’re ready to move to Gateway API 

What about other options? Gateway API is the future, but it’s still maturing. Traefik, HAProxy, Kong are all fine, but if you’re already using NGINX and want the smoothest path forward, NGINX Ingress Controller will be, we believe, the best option. (We are biased, of course). 

Get Started Today 

Ready to begin your migration? Here’s what you need: 

📚 Read the full documentation: NGINX Ingress Controller Docs 

💻 Clone the repository: github.com/nginx/kubernetes-ingress 

🐳 Pull the image: Docker Hub – nginx/nginx-ingress 

🔄 Follow the migration guide: Migrate from Ingress-NGINX to NGINX Ingress Controller 

The NGINX Ingress Controller community is responsive and full of passionate builders — join the conversation in the GitHub Discussions or the NGINX Community Forum. You’ve got time to plan this migration right, but don’t wait until March 2026 to start.