Hello to our Kubernetes community! Over the past few months, the F5 NGINX Community and F5 NGINX Kubernetes teams have been working on reinvigorating our open source presence. One of our new initiatives involves having public roadmaps available through GitHub Projects boards for both the NGINX Ingress Controller and NGINX Gateway Fabric project! We also aim to publish roadmap update blogs twice a year to talk about our roadmap more in depth. Here at F5 we believe you should know what we’re building next and why, so you can plan any future Kubernetes decisions with that context and let us know any feedback you have about the roadmap through any of our community channels!
Here’s where both projects are headed in in the first half of 2026.
NGINX Ingress Controller: Listening to the Community
The NGINX Ingress Controller uses the Ingress API by default, the same as any other Ingress Controller. NGINX Ingress Controller also has a CRD-based configuration model that gives operators structured, validated control over their ingress. It’s been running in production clusters for years, and it’s not slowing down.
We’ve heard the community, and over the next few releases, we are prioritizing bringing features that ingress-nginx users depend on into NGINX Ingress Controller. We are extending our support for ingress-nginx annotations with 1-to-1 mappings, external auth support lands in the next major NGINX Ingress Controller release, and session persistence will be coming to NGINX Ingress Controller later this year. In addition, we will be launching a comprehensive migration guide from ingress-nginx to NGINX Ingress Controller within the next couple weeks, as well as a community landing page covering all of our Kubernetes efforts.
Expanding ingress-nginx Annotation Compatibility
One of the most consistent requests we’ve gotten is broader compatibility with ingress-nginx annotations. If you’re migrating NGINX Ingress Controller, you shouldn’t have to rewrite your ingress configuration from scratch. We’ve been working on this steadily, and the list of supported annotations has grown fast. Over the next few releases we plan to keep adding support for ingress-nginx annotations.
ingress-nginx Annotations that will be supported in our next major release:
nginx.ingress.kubernetes.io/rewrite-targetnginx.ingress.kubernetes.io/client-body-buffer-sizenginx.ingress.kubernetes.io/ssl-ciphersnginx.ingress.kubernetes.io/ssl-redirectnginx.ingress.kubernetes.io/force-ssl-redirectnginx.ingress.kubernetes.io/next-upstreamnginx.ingress.kubernetes.io/next-upstream-timeoutsnginx.ingress.kubernetes.io/next-upstream-triesnginx.ingress.kubernetes.io/whitelist-source-rangenginx.ingress.kubernetes.io/app-rootnginx.ingress.kubernetes.io/auth-signinnginx.ingress.kubernetes.io/auth-urlnginx.ingress.kubernetes.io/enable-cors
ingress-nginx Annotations that are on the roadmap:
nginx.ingress.kubernetes.io/proxy-redirect-fromnginx.ingress.kubernetes.io/proxy-redirect-tonginx.ingress.kubernetes.io/custom-http-errorsnginx.ingress.kubernetes.io/auth-tls-verify-clientnginx.ingress.kubernetes.io/auth-tls-secretnginx.ingress.kubernetes.io/auth-tls-verify-depthnginx.ingress.kubernetes.io/proxy-http-versionnginx.ingress.kubernetes.io/add-header
It’s worth noting that all of the above annotations will use the NGINX Ingress Controller annotation standards and replace the nginx.ingress.kubernetes.io/ annotation prefix with nginx.org/, and that we are also planning to add new annotations that we think are complimentary to existing NGINX directives such as ssl-redirect-return-code, to be used in conjunction with ssl-redirect.
Improved Resiliency and Expanded Features
Beyond annotations, we have a few features coming in the first half of the year focused on improving the overall resiliency of NGINX Ingress Controller as well as implementing key features such as external auth and session persistence that will heavily facilitate users migrating from ingress-nginx to NGINX Ingress Controller:
Configuration Resilience (“Safety”) improves how NGINX Ingress Controller handles bad or conflicting configurations. If someone applies a broken config, NGINX Ingress Controller should handle it gracefully instead of taking down your routes.
Rate Limiting based on NGINX variables lets you key rate limits off headers, client attributes, or custom variables, not just IP addresses.
Cache Policy and StatefulSet support bring native caching policy and StatefulSet deployment options to NGINX Ingress Controller.
New CRDs for External Auth and CORS expand NGINX Ingress Controller’s CRD-based configuration model. External auth is one of the most requested features from teams migrating off ingress-nginx, and it’s the headline feature of the March 17th release.
Session Persistence moves to Open Source: This was previously commercial-only. If you’re running stateful workloads (shopping carts, multi-step forms, authentication flows), you’ll no longer need NGINX Plus for sticky sessions.
Cross Namespace support lets you route traffic to services across namespace boundaries.
Argo Rollouts deployment option adds support for progressive delivery workflows with Argo.
Availability in Nutanix Kubernetes Platform: Nutanix and F5 joined forces to deliver NGINX Ingress Controller running on the Nutanix Kubernetes Platform (NKP) solution.
Looking Further Ahead
We also have a few items on the roadmap slated for the second half of 2026 that we thought might be of interest to the community! None of these features are confirmed and things might change over the new few months, but we’re exploring implementing the following features starting later this year:
- HSTS Policy and HTTP/2 to service.
- Scoped Ingress Controller deployments with namespace isolation, a frequently requested feature for multi-tenant clusters.
- Advanced caching.
- Forward proxy support and native MQTT protocol handling move to Open Source and come to NGINX Ingress Controller.
- GeoIP-based routing and hot reload without dropping connections.
- Bringing our Images back to the cloud marketplaces!
- Sharded cache cluster support (split a cache across multiple volumes!)
NGINX Gateway Fabric: Gateway API-Native and AI-Ready
NGINX Gateway Fabric (NGF) is the Gateway API-native Kubernetes solution from NGINX. Recent releases delivered TCP/UDP routing, rate limiting, and the Ingress2Gateway migration provider. Now the focus shifts to core traffic management gaps and, increasingly, AI infrastructure.
Already Delivered
Over the past few releases, NGINX Gateway Fabric has added support for the following features:
Gateway API Inference Extension: NGINX Gateway Fabric can serve as a gateway for AI model endpoints. You manage model routing through the same Gateway API resources you use for everything else.
Red Hat OpenShift Certification: NGINX Gateway Fabric has become an officially supported option for OpenShift environments.
TCPRoute and UDPRoute Support: Users can consolidate traffic management into a single Gateway API workflow instead of deploying separate load balancers for non HTTP services.
Authentication via AuthenticationFilter CRD: The new AuthenticationFilter adds HTTP Basic Auth, allowing you to protect routes with credentials. Future releases will extend AuthenticationFilter beyond the baseline with additional methods available.
RateLimit Policy CRD: Enhanced traffic control with a new RateLimitPolicy CRD, enabling HTTP rate limiting directly through Gateway API.
Regex-based path matching, redirects, header modification, and NGINX Snippets fill traffic shaping gaps that power users have been asking for.
Routing to external services via ExternalName, plus customizable logging and basic auth filters.
mTLS and cipher configuration through the Gateway API and a new TLS Options resource give operators finer control over transport security.
Looking Further Ahead
Over the next few months, we are hoping to add support for the following features:
- External auth and CORS.
- Session persistence moves to open source (same as NGINX Ingress Controller).
- HTTP/2 to backend services, which improves performance for gRPC workloads.
- MCP (Model Context Protocol) and A2A (Agent-to-Agent) support. These protocols are how AI agents discover tools and talk to each other. Native gateway support means no custom middleware between your agents and the rest of your stack.
- Forward proxy, east/west traffic control, and egress control, pushing NGINX Gateway Fabric beyond traditional north/south ingress.
- Caching and gzip compression.
- API key auth and access control (whitelisting).
What Ties It All Together
A few things stand out across both projects.
Open source is at the heart of both projects. The NGINX Ingress Controller and NGINX Gateway Fabric communities are growing, and so is our commitment to building avenues for connection. From your feedback to your questions to your PRs, we love hearing from you.
We develop in the open. Both the NGINX Ingress Controller and NGINX Gateway Fabric teams have public project boards on GitHub and regularly host community calls. We want our users to know what we are actively working on, see how we triage issues and PRs, and answer any questions they might have around our projects.
Community feedback is driving our roadmaps. The ingress-nginx annotation compatibility work, the new CRDs (external auth and CORS), and the open-sourcing of session persistence all came directly from what users have been telling us. That feedback loop is working, and we want to keep it going.
AI workloads are shaping our direction. The Gateway API Inference Extension, MCP, and A2A support reflect the reality that inference traffic needs the same routing, rate limiting, and session management as any other workload. GPU resources are expensive, and intelligent routing at the gateway helps you use them efficiently.
We are actively exploring open sourcing commercial features where possible. Our second foray (after open sourcing service discovery) is open sourcing session persistence (via sticky sessions) across the board. Both NGINX Ingress Controller and NGINX Gateway Fabric are getting this. It was previously commercial-only, and we think making it freely available is the right call. We also plan on open sourcing forward proxying and MQTT further down the line.
NGINX Ingress Controller and NGINX Gateway Fabric are complementary, not competing. NGINX Ingress Controller continues to evolve its CRD model with new resource types. NGINX Gateway Fabric is built entirely on Gateway API. If you’re on CRDs today, NGINX Ingress Controller has a clear path forward. If you’re adopting Gateway API, NGINX Gateway Fabric is ready. And if you’re planning a move from one to the other, we’re building tooling to make that easier too.
Get Involved
This is the first time we’ve published a roadmap like this, and we plan to keep doing it! If you have feedback or want to influence what gets prioritized, here’s where to find us: