If you’re running Kubernetes, there’s a good chance you rely on ingress-nginx to route external traffic to your workloads. For years, ingress-nginx has been the go-to open source ingress controller, valued for its reliability and broad community support, data collected for our recently published State of Kubernetes Networking report, shows that 50% of respondents use Ingress-nginx today. But that’s about to change. Archival of Ingress-nginx: What Does This Mean for You? The maintainers of ingress-nginx have announced that the project is being archived at the start of 2026. This means it will no longer receive active maintenance, security patches, or bug fixes. The news, unveiled during KubeCon, marks a significant turning point for thousands of Kubernetes users and organizations that have built their ingress strategy around it. Before we get into migration options, it’s worth noting that some organizations need more than just a replacement controller. They need hardened builds, long-term maintenance, FIPS-validated components, and enterprise-grade SLAs. That’s why companies such as Adobe and Roche turn to Isovalent Networking for Kubernetes, the enterprise distribution of Cilium built for production environments with extended support and additional integrations. This post focuses on the open source path with Cilium, but if your requirements demand enterprise-grade assurance, contact Isovalent to learn more about our supported offering. What Are Your Options? With ingress-nginx entering retirement, platform teams face a choice: keep a critical control-plane component without upstream maintenance, or move to an actively supported alternative. The Kubernetes community has also aligned on the Gateway API as the long-term standard for traffic management. That direction shapes your two primary migration paths: Move to another ingress controller (such as Cilium Ingress, Traefik, or HAProxy Ingress). Adopt the Kubernetes Gateway API, the next-generation standard for ingress and traffic management, using a controller like Cilium Gateway API. Cilium offers both. You can start with Cilium Ingress for a drop-in replacement and later transition to the Gateway API without switching vendors, controllers, or datapaths. Option 1 - Quickest: Moving to Cilium Ingress Cilium Ingress is a drop-in ingress controller that supports standard Kubernetes Ingress resources. It runs on Cilium’s eBPF-powered datapath, which provides excellent performance, deep visibility, and seamless integration with Cilium Network Policies. Why Teams Choose This Path Minimal changes to application manifests and CI/CD pipelines. Continuity in using an actively maintained product and a clean path away from NGINX-specific annotations. Built-in observability and stronger security through Cilium’s tooling. What to Watch Out For NGINX-only annotations and custom directives will not translate directly. If you rely on complex rewrites or advanced NGINX behaviours, plan a validation phase to map those features to Cilium equivalents, or consider the Gateway API for richer routing capabilities. How to Migrate from ingress-nginx to Cilium Ingress: 1. Inventory current Ingress usage: Record hosts, paths, TLS settings, annotations, rewrite rules, and rate limits. 2. Install or verify Cilium: Follow the Cilium Getting Started guide 3. Enable Cilium Ingress: See Cilium Ingress documentation. 4. Update manifests to target Cilium’s ingress class: Switch ingressClassName to cilium and remove NGINX-specific annotations where appropriate. 5. Validate and cut over: Test TLS, path routing, and network policies in staging before switching production traffic. Option 2 - Recommended: Upgrading to Cilium’s Gateway API Implementation While switching to Cilium Ingress is the fastest way to move off ingress-nginx, the Kubernetes ecosystem is shifting towards the Gateway API. A subproject of SIG-Network, Gateway API is the successor to Ingress, covering not just north-south traffic but also east-west and service-mesh entry points through a consistent, extensible model. Cilium’s implementation supports all Core Gateway API resources and features, in addition to most Extended (or optional) features and enhances them with eBPF-powered performance, observability, and policy integration. Why Choose Cilium's Gateway API implementation? Cilium's Gateway API implementation isn't just a replacement; it's an upgrade that brings a host of benefits, from enhanced traffic control to streamlined operations. Advanced traffic management: Native support for header-based routing, traffic splitting, and cross-namespace routes. Unified traffic management (GAMMA): Leverage a single, consistent API (Gateway API) to manage both external (north-south) ingress traffic and internal (east-west) service mesh traffic, simplifying operations and policy enforcement. Role separation: Decouple infrastructure from application routing for better security and multi-tenancy. Rich policy integration: Combine L7 routing with Cilium Network Policies and Hubble observability. Future alignment: Gateway API is the endorsed standard by Kubernetes SIG-Network and major cloud providers. What are the key features over Ingress? While Ingress has served us well, its design inherently limits advanced traffic management. The Gateway API, especially with Cilium's implementation, unlocks a new level of control and flexibility. This table highlights some key areas where Gateway API goes beyond what traditional Ingress can offer, providing more robust and granular control over your traffic flows. Migrating to Cilium's Gateway API implementation: Ensure Cilium is installed and configured for Gateway API: Cilium Gateway API Docs Install Gateway API CRDs: If your Kubernetes distribution does not ship with Gateway API, install CRDs as per Gateway API Installation Guide. Define GatewayClass and Gateway resources: Here is a simple example, you can find more details examples in our tutorial blog post for Gateway API, or by visiting our labs: 4. Translate Ingress rules into HTTPRoute objects: The new model offered by Gateway API allows for Application teams define routes and backends, optionally with cross-namespace references. Removing this task from responsibility of the platform owner. 5. Test advanced features: Try features such as header-based routing, traffic splitting, and cross-namespace scenarios as needed in staging/development and promote into production as needed. These are capabilities not previous available with Kubernetes Ingress. Use the Ingress-to-Gateway migration tool For teams with many Ingress resources, manual translation can be tedious. Isovalent’s Christine Kim, published a guide, How to Migrate from Kubernetes Ingress to Gateway API, which introduces a migration utility that automates much of the conversion process. For large estates, manually translating every Ingress is slow and error prone. The Kubernetes SIG Network utility ingress2gateway converts existing Ingress resources into Gateway API resources, either by reading from your current kubeconfig or from input files. This gives you a solid starting point that you can review and apply with Cilium Gateway API enabled. The below is an example of running the tool specifying Cilium as the destination output. The tool can also run against a cluster and print equivalent Gateways and HTTPRoutes, which you can pipe to files for version control. You can get hands on with this tool in our hands on lab "Cilium Ingress Controller" where you will learn how you can use Cilium to deploy Ingress resources and then also migrate to Gateway API, the successor for Kubernetes traffic management. Which path should you take first? Most teams start with Cilium Ingress to remove the maintenance risk immediately, then move to the Gateway API as their routing and organizational needs evolve. If your platform already separates infrastructure and application teams, Gateway API will feel natural from the start. If your environment is smaller or less complex, Cilium Ingress offers the fastest path to replace ingress-nginx with minimal change. A practical migration plan: Document current behaviour: Capture hosts, paths, TLS, health checks, and any NGINX annotations. Select a target: Choose Cilium Ingress for quick replacement, or Gateway API for long-term flexibility. Deploy and test: Install Cilium, configure DNS and certificates, and enable Hubble for visibility. Run side-by-side: Mirror traffic and validate behaviour before cutting over. Switch production: Redirect DNS or load balancer targets, monitor closely, and keep a rollback plan. Iterate: Once stable, identify services that can benefit from Gateway API features and migrate them next. Why Cilium is a sensible default: Preparing for the Future The deprecation of ingress-nginx is a pivotal moment for Kubernetes networking. Rather than patching together point solutions, this is your opportunity to adopt a unified, eBPF-powered platform built for performance, visibility, and security. Cilium gives you: A drop-in Ingress replacement: Minimal migration pain, maximum reliability. A best-in-class Gateway API implementation: Unlock powerful new features and future-proof your stack. Unified observability and security: Deep insights and fine-grained controls out of the box. Active support and rapid innovation: Cilium is trusted by major cloud providers and community leaders, with enterprise support provided by Isovalent. Continue Your Journey Try the Cilium Ingress Controller Lab: Learn how to deploy, migrate, and test using Ingress2Gateway in a live environment. Take the Cilium Gateway API Lab: Explore advanced routing, cross-namespace delegation, and service-mesh entry points. Read Christine Kim’s migration guide: Understand the practical considerations behind adopting the Gateway API. Don’t wait until your ingress controller becomes a liability. Start your migration today and set your infrastructure up for long-term success with Cilium.