Ingress NGINX replacements compared

Which Ingress NGINX replacement suits each team

This table maps common team situations to the replacement most likely to fit, with the condition that makes each choice hold. Read each row against your own cluster, annotation inventory and deadline, and treat any annotation support as something to verify before migration begins.

How much migration effort each option asks for

How each Ingress NGINX replacement compares on Gateway API and licensing

This table compares Envoy Gateway, Traefik, Kong Ingress Controller and APISIX Ingress Controller on license, release, Gateway API support, ingress-nginx annotation migration, authentication, extensions, deployment modes, air-gapped guidance and commercial tiers. Where a cell says to confirm, the public information available for this comparison does not settle the point, so check it with the project or vendor before you shortlist. Envoy Gateway and Traefik have the clearest published Gateway API support, and Traefik is the only option here with documented ingress-nginx annotation support.

What each replacement is and where it stops

Each option below is a current open-source choice for ingress or Gateway API traffic. They differ most in whether they follow the Gateway API, whether migration keeps your existing annotations, and which commercial line holds the newest features.

Where open-source licenses end and paid editions begin

How to choose and pilot a replacement

This sequence turns the retirement of Ingress NGINX into a documented, reversible decision: you inventory what you run, shortlist two controllers, prove the choice in a pilot, and leave with a cutover and rollback plan you can hand to change control.

1. Inventory every ingress resource

   Platform or cluster engineers list every Ingress object, IngressClass and ingress-nginx annotation and configuration snippet across all clusters, including Helm values and GitOps repositories that generate them. Export the list with the owning team, the hostname, the TLS source and whether the route carries authentication, rate limits or custom server blocks. Snippets and custom templates are the items most likely to need rewriting, so flag them first. The step is done when every route is in one inventory and each has an owner.

2. Classify each annotation and snippet

   Working with the application owners, sort each item into supported, rewritable or unsupported. Supported means the candidate controller accepts the same annotation with the same behavior, which you must confirm in its documentation rather than assume. Rewritable means the intent maps to Gateway API resources or a controller-specific policy. Unsupported means the behavior needs a redesign or a plugin you have not yet verified. Record the classification in the inventory. The output is a short list of blockers that will drive the controller shortlist.

3. Shortlist two controllers

   Choose two candidates from Envoy Gateway, Traefik with its Ingress NGINX provider, Kong Ingress Controller and the APISIX Ingress Controller, based on the blockers from the previous step. Confirm the licence of each controller and of the gateway it runs, and whether any feature you need sits in a paid edition. Ask each vendor or project in writing which annotations it supports, which Gateway API version it targets and what its support window is for the release you would deploy. The step is done when you have a written comparison for two options that your architects accept.

4. Pilot on one non-critical namespace

   Deploy both shortlisted controllers into a test cluster or one low-risk namespace, and move a representative set of routes from the inventory, including at least one route with authentication and one with TLS passthrough or custom headers. Run the same traffic tests against each and record latency, error rates and the number of manual edits each route needed. Because existing Ingress NGINX deployments keep working after retirement, this pilot does not need a compressed schedule. Done means a results sheet that compares the two controllers on the same routes.

5. Check Gateway API conformance and auth flows

   Test the Gateway API resources each controller generates against the conformance results it publishes, and confirm which features are in scope for your version. Then test every authentication flow your applications depend on, such as OIDC, JWT validation, mutual TLS, external authorization and IP allow lists, end to end with a real identity provider in the pilot environment. Ask each vendor which of these features are included in the open-source edition and which require a commercial license. The output is a pass or fail record per flow, with any gap logged as a blocker or an accepted risk.

6. Document the security and operations model

   Security and platform teams review how each candidate handles certificate management, logging, metrics, upgrades and the separation of control and data planes. Confirm the upgrade path and release cadence for each controller in writing, including how long each version receives fixes. Identify who will own the controller after go-live and what runbooks they need. The step is done when the review produces a signed decision record that names the controller, the reasons and the open risks.

7. Plan cutover and rollback

   Platform engineers write a cutover plan that moves routes in batches, keeps the existing Ingress NGINX controller running in parallel, and uses DNS or load balancer weights to shift traffic gradually. Each batch needs a named owner, a health check that confirms success and a rollback step that restores the previous route. Schedule removal of the old controller only after every batch has stayed healthy through an agreed observation period. The output is an approved runbook and a rollback test that you have rehearsed in the pilot environment.

What running each controller asks of your platform team

Questions buyers ask before hiring outside help