Ingress-Nginx served as the default traffic gateway for Kubernetes clusters since the early days of K8s. That era ended in March 2026 when the Kubernetes SIG Network and Security Response Committee officially halted maintenance. No more releases, no more bugfixes, and no more security patches.

If you run K8s or K3s on a VPS — whether for internal tools, SaaS backends, or self-hosted apps — this directly affects you. Roughly half of all Kubernetes environments use Ingress-Nginx, and Kubernetes 1.36 (releasing April 22, 2026) marks the full transition to Gateway API as the official networking standard.

Here is what happened, what replaces it, and how to migrate without downtime.

Why Ingress-Nginx Was Retired

The project did not fail because of a technical flaw. It failed because of maintainer exhaustion. By 2025, only one or two people were maintaining the controller on personal time. The Kubernetes Security Response Committee flagged several annotation-based features — originally designed for flexibility — as security liabilities.

An attempt to build a replacement called InGate never gained enough contributors. Public calls for new maintainers went unanswered. The SIG Network team decided that continuing to ship an under-maintained component with known security risks was worse than retiring it outright.

The timeline:

  • November 2025: Official retirement announcement
  • March 2026: Maintenance halted — no further releases or patches
  • April 22, 2026: Kubernetes 1.36 ships with Gateway API as the official networking standard

Existing deployments still function. Helm charts and container images remain available. But running an unpatched ingress controller in production is a ticking clock, especially for anything handling authentication tokens, API keys, or customer data.

What Replaces It: The Gateway API

Gateway API is the official successor to the Ingress resource type. It was designed from the ground up to fix the problems that made Ingress difficult to manage at scale.

The core difference is architectural. Ingress combined the load balancer definition and routing rules into a single resource. Gateway API splits them:

  • Gateway: Defines where and how traffic enters the cluster (ports, protocols, TLS)
  • HTTPRoute: Defines how traffic is routed to backend services
  • GatewayClass: Specifies which controller implementation handles the Gateway

This separation means platform teams can manage the Gateway (infrastructure concerns like certificates and IP addresses) while application teams manage their own HTTPRoutes (routing rules and path matching) independently.

Gateway API vs Ingress: Key Differences

Feature Ingress Gateway API
Resource model Single resource Split: Gateway + HTTPRoute
Role separation None Platform team vs app team
Header-based routing Annotation hacks Native support
Traffic splitting Not supported Native (weighted backends)
Request mirroring Not supported Native support
TCP/UDP routing Limited TCPRoute / UDPRoute
Cross-namespace routing Not supported ReferenceGrant
Vendor extensions Annotations (unstructured) Policy attachments (typed)

Choosing a Gateway API Controller

Gateway API is a specification, not an implementation. You need a controller that implements it. The main options for self-hosted Kubernetes on a VPS:

Envoy Gateway

Envoy Gateway is the reference implementation backed by the Envoy proxy project. It has full Gateway API conformance and strong community momentum. If you have no existing preference, start here.

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 \
  -n envoy-gateway-system --create-namespace

Traefik

Traefik has supported Gateway API since v3.0. If you already use Traefik as a reverse proxy (many self-hosted setups do), you can enable Gateway API support alongside your existing IngressRoute configuration and migrate incrementally.

Cilium

If you run Cilium as your CNI, its Gateway API support is built into the networking layer. No separate controller needed. This is the most resource-efficient option but requires Cilium as your CNI.

Istio

Istio’s ambient mode now supports Gateway API natively. Best suited for environments that already use or plan to use a service mesh. Heavier than the other options.

Step-by-Step Migration

Step 1: Audit Your Current Ingress Resources

Start by identifying every Ingress resource and Ingress-Nginx annotation in your cluster:

# Find all Ingress-Nginx pods
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# List all Ingress resources
kubectl get ingress --all-namespaces -o wide

# Export for review
kubectl get ingress --all-namespaces -o yaml > ingress-backup.yaml

Pay special attention to annotations. Standard path and host routing translates cleanly. Custom annotations for rewrites, CORS, rate limiting, and auth require manual review.

Step 2: Install ingress2gateway

The Kubernetes project released ingress2gateway 1.0 on March 20, 2026 — purpose-built for this migration. It converts your Ingress manifests to Gateway API resources and flags anything it cannot translate.

# Install via Homebrew
brew install ingress2gateway

# Or via Go
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

Step 3: Convert Your Manifests

Run the tool against your existing Ingress resources:

# Convert from files
ingress2gateway print \
  --input-file ingress-backup.yaml \
  --providers=ingress-nginx > gateway-api.yaml

# Or convert directly from a namespace
ingress2gateway print \
  --namespace production \
  --providers=ingress-nginx > gateway-api.yaml

# Or scan the entire cluster
ingress2gateway print \
  --providers=ingress-nginx \
  --all-namespaces > gateway-api.yaml

The tool supports 30+ common Ingress-Nginx annotations including CORS, backend TLS, regex matching, path rewrites, proxy timeouts, custom headers, and request body size limits.

Review the output carefully. The tool will print warnings for any configuration it cannot convert. These warnings are the items that need manual attention.

Step 4: Deploy Side-by-Side

This is the safest approach: run your new Gateway API controller alongside the existing Ingress-Nginx controller. Each gets its own external IP address, so you can test without affecting production traffic.

# Install Gateway API CRDs
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml

# Install your chosen controller (example: Envoy Gateway)
helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 \
  -n envoy-gateway-system --create-namespace

# Apply your converted Gateway API resources
kubectl apply -f gateway-api.yaml

# Verify the Gateway gets an external address
kubectl get gateway -A

Step 5: Test and Switch DNS

Once your Gateway API controller is serving traffic correctly on its new IP:

  1. Update your DNS records (or load balancer) to point to the new Gateway IP
  2. Monitor error rates, latency, and connection counts
  3. Keep Ingress-Nginx running for 48-72 hours as a fallback
  4. Once validated, remove the old Ingress-Nginx deployment

If you use a reverse proxy like Caddy in front of your cluster, update the upstream target to the new Gateway IP.

Common Migration Pitfalls

Annotation gaps. Not every Ingress-Nginx annotation has a Gateway API equivalent. Rate limiting, Lua snippets, and custom error pages often need policy attachments or implementation-specific extensions. The ingress2gateway tool flags these — do not ignore the warnings.

TLS termination changes. In Ingress, TLS was configured on the Ingress resource. In Gateway API, TLS lives on the Gateway listener. If you manage certificates with cert-manager, update your Certificate resources to reference the Gateway instead.

Default backend behavior. Ingress-Nginx had a default backend for unmatched requests. Gateway API does not. You need an explicit catch-all HTTPRoute if you want the same behavior.

Session affinity. Ingress-Nginx’s nginx.ingress.kubernetes.io/affinity annotation has no direct Gateway API equivalent. You will need an implementation-specific policy (e.g., Envoy Gateway’s BackendTrafficPolicy).

What If You Cannot Migrate Yet?

If your migration timeline extends beyond March 2026, you have two short-term options:

  1. Chainguard’s maintained fork — Chainguard’s EmeritOSS program maintains the final Ingress-Nginx release with CVE patches (no new features). This buys time without running unpatched software.
  2. Pin and isolate — Lock your Ingress-Nginx version, restrict network access to the controller, and add a WAF layer. This is a stopgap, not a solution.

Neither approach is a long-term answer. Plan your migration now. The Docker v29 breaking changes already taught many self-hosters what happens when you delay infrastructure updates.

Running K8s on a VPS: Where This Fits

If you run K3s or a single-node K8s cluster on a VPS for self-hosted applications, this migration is actually simpler than in large multi-cluster environments. You likely have a handful of Ingress resources, straightforward routing, and full control over your DNS.

The biggest risk is not complexity — it is inaction. An unpatched ingress controller handling TLS termination is the front door to your cluster.

For VPS-based Kubernetes workloads, a Cloud VPS with full root access gives you the flexibility to run any Gateway API controller. If you need help with the migration, CWH Managed Support can handle the setup.

For teams running monitoring stacks alongside their applications, make sure your new Gateway controller exposes Prometheus metrics — Envoy Gateway and Traefik both do this out of the box.

Next Steps

  1. Run the audit commands above to inventory your Ingress resources
  2. Install ingress2gateway and convert your manifests
  3. Deploy a Gateway API controller side-by-side with Ingress-Nginx
  4. Test, switch DNS, and decommission the old controller before the April 22 K8s 1.36 release

The Ingress-Nginx project served the Kubernetes community well for years. Its retirement is not a crisis — it is a planned transition to something better. The tools exist, the migration path is documented, and the timeline is clear. Start now.