For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

The Ingress NGINX Alternative: F5 NGINX Ingress Controller for the Long Term

The Kubernetes community recently announced that Ingress NGINX will be retired in March 2026. After that date, there won’t be any more new updates, bugfixes, or security patches. ingress-nginx is no longer a viable enterprise solution for the long-term, and organizations using it in production should move quickly to explore alternatives and plan to shift their workloads to Kubernetes ingress solutions that are continuing development. 

 

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

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. Security start-up Chainguard is maintaining a status-quo version of ingress-nginx and applying basic safety patches as part of their EmeritOSS program. But this program is designed as a stopgap to keep users safe while they transition to a different ingress solution.  

F5 maintains an OSS permissively licensed NGINX Ingress Controller.  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 significant learning curve, we believe that the F5 NGINX Ingress Controller for Kubernetes is your smoothest path forward. 

 The benefits of adopting NGINX Ingress Controller open source include:  

  • 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. Supported annotations include popular ones such as  
    • nginx.org/client-body-buffer-size mirrors nginx.ingress.kubernetes.io/client-body-buffer-size (sets the maximum size of the client request body buffer). Also available in VirtualServer and ConfigMap.  
    • nginx.org/rewrite-target mirrors nginx.ingress.kubernetes.io/rewrite-target (sets a replacement path for URI rewrites)  
    • nginx.org/ssl-ciphers mirrors nginx.ingress.kubernetes.io/ssl-ciphers (configures enabled TLS cipher suites)  
    • nginx.org/ssl-prefer-server-cipher mirrors nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers (controls server-side cipher preference during the TLS handshake) 
  • Optional enterprise-grade capabilities: While the OSS version is robust, NGINX Plus integration is available for enterprises needing high availability, authentication and authorization, session persistence, advanced security and commercial support 
  • Sustainable maintenance: A dedicated full-time team at F5 ensures regular security updates, bug fixes, and feature development.  
  • Production-tested at scale: NGINX Ingress Controller 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. NGINX Gateway Fabric is a conformant Gateway API solution under CNCF conformance criteria and it is one of the most widely used open source Gateway API solutions. 

 

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 annotations like:   

    nginx.ingress.kubernetes.io/configuration-snippet
  • 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 

 

Enterprise-grade capabilities and support  

Once an ingress layer becomes mission-critical, enterprise features become necessary.  High availability, predictable failover, and supportability matter as much as features. Enterprise-grade capabilities available for NGINX Ingress Controller Plus include high availability, authentication and authorization, commercial support, and more. These ensure production traffic remains fast, secure, and reliable. Capabilities include: 

Commercial support 

  • Backed by vendor commercial support (SLAs, escalation paths) for production incidents 
  • Access to tested releases, patches, and security fixes suitable for regulated/enterprise environments 
  • Guidance for production architecture (HA patterns, upgrade strategies, performance tuning) 
  • Helps organizations standardize on a supported ingress layer for platform engineering at scale 

Dynamic Reconfiguration 

  • Upstream configuration updates via API without process reloads 
  • Eliminates memory bloat and connection timeouts as upstream server lists and variables are updated in real time when pods scale or configurations change 

Authentication & Authorization 

  • Built-in authentication support for OAuth 2.0 / OIDC, JWT validation, and basic auth 
  • External identity provider integration (e.g., Okta, Azure AD, Keycloak) via auth request patterns 
  • JWT validation at the edge, including signature verification, claims inspection, and token expiry enforcement 
  • Fine-grained access control based on headers, claims, paths, methods, or user identity 

Optional Web Application Firewall 

  • Native integration with F5 WAF for NGINX for OWASP Top 10 protection, gRPC schema validation, and OpenAPI enforcement 
  • DDoS mitigation capabilities when combined with F5 security solutions 
  • Centralized policy enforcement across multiple ingress resources 

High availability (HA) 

  • Designed to run as multiple Ingress Controller replicas in Kubernetes for redundancy and scale 
  • State sharing: Maintains session persistence, rate limits, and key-value stores for seamless uptime. 

 

Here’s the full list of differences between NGINX Open Source and NGINX One – a package that includes NGINX Plus Ingress Controller, NGINX Gateway Fabric, F5 WAF for NGINX, and NGINX One Console for managing NGINX Plus Ingress Controllers at scale. 

 

Get Started Today 

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

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. 

Published Jan 08, 2026
Version 1.0
application delivery
deployment
devops
kubernetes
Kubernetes Ingress Controller
NGINX
nginx one
NGINX Plus
security
No CommentsBe the first to comment