NGINX Is Back: Gateway Fabric vs Envoy vs Cilium for Your Self-Hosted PaaS

If you run a self-hosted PaaS, March 2026 already made your gateway decision for you — you just haven't finished executing it. The community ingress-nginx controller entered retirement with best-effort maintenance ending in March 2026, and the Kubernetes project points at Gateway API as the long-term replacement. Every tenant domain you serve now funnels through whatever you pick next, which makes the gateway the highest-blast-radius component on your fleet.

Here is the verdict up front: for a Cluster API fleet serving many small tenant apps, default to Envoy Gateway unless you have a concrete reason not to — an existing NGINX annotation estate that makes migration cost dominate, or an existing Cilium CNI that makes a single eBPF stack worth the coupling. The table below is the whole argument; the rest of this post is the evidence, including what F5's March 2026 roadmap actually changes about the NGINX option.

The short version: F5 reinvesting in open source makes NGINX a credible Gateway API bet again — but "credible" and "default" are different claims, and a PaaS operator should tell them apart.

To keep this comparison honest, fix the workload first. The "typical" app behind a git-push PaaS is not one fat API with huge payloads. It is ~200 small tenant services, each with its own hostname and TLS certificate, mostly HTTP/1.1 and HTTP/2 with occasional gRPC, frequent deploys, frequent route churn, and per-tenant expectations that one tenant's bad config cannot take down the other 199. Throughput per route is modest; route count, certificate count, config-reload safety, and per-tenant observability dominate. Any benchmark that measures a single route at maximum bytes per second is measuring something other than this.

What F5 actually promised in March 2026​

The signal behind "NGINX is back" is a real post, not a vibe: Micheál Kingston and Alessandro Fael Garcia published The NGINX Kubernetes Open Source Roadmap: First Half of 2026 on March 12, 2026. Three process changes matter more than any single feature:

• Public roadmaps on GitHub Projects for both NGINX Ingress Controller and NGINX Gateway Fabric, plus a commitment to twice-yearly roadmap posts. You can plan against something visible instead of guessing.
• Community feedback driving the list. Annotation compatibility, external auth, CORS, and open-sourcing session persistence all came directly from migration pain.
• NGINX Ingress Controller and NGINX Gateway Fabric framed as complementary, not competing. CRD-model users get a path forward; Gateway API adopters get NGF; tooling (ingress2gateway provider) bridges the two.

The concrete H1 2026 items for migrators:

• 1:1 ingress-nginx annotation mappings into nginx.org annotations (for example rewrite-target, ssl-redirect, force-ssl-redirect, app-root, client-body-buffer-size, ssl-ciphers, upstream retry trio), with a second batch (CORS, source-range whitelisting) delivered combined with the Policy CRD, and auth annotations (auth-url, auth-signin, TLS client verification) further down the roadmap.
• External auth and session persistence landing in open source — sticky sessions move out of NGINX Plus-only into both Ingress Controller and Gateway Fabric.
• Resilience work: graceful handling of bad/conflicting config instead of taking routes down, variable-keyed rate limiting, cache policy and StatefulSet support, cross-namespace routing, Argo Rollouts deployment option.
• On the NGF side specifically: TCPRoute/UDPRoute support, AuthenticationFilter (basic auth baseline), RateLimitPolicy CRD, regex path matching, redirects, header modification, NGINX snippets, ExternalName backends, mTLS via BackendTLSPolicy, OpenShift certification, and Gateway API Inference Extension support for model endpoints.
• H2 2026 exploration: external auth and CORS completion on NGF, HTTP/2 to backends (helps gRPC), MCP and agent-to-agent protocol support, east/west and egress control, caching, gzip, API-key auth, plus scoped multi-tenant Ingress Controller deployments.

Two adjacent F5 moves reinforce the signal: NGF now constitutes the majority of NGINX Kubernetes traffic-management downloads per the NGINX Gateway Fabric 2.3.0 notes, and F5 debuted WAF for NGINX on Gateway Fabric with Red Hat in May 2026. A vendor putting its security story on the Gateway API implementation is a stronger commitment signal than a blog post alone.

What F5 did not promise: instant Gateway API v1.5 conformance. NGF 2.3.0 certifies against Gateway API v1.4.1. The v1.5 Standard channel (February 2026) graduated a batch of previously experimental surface — GRPCRoute, BackendTLSPolicy, ReferenceGrant, and TLS-adjacent behavior among them, with CORS filters and Gateway merging in the same wave — and every implementation needs a catch-up release before tenants can rely on the new stable surface. Treat "supports Gateway API" as versioned, and check the conformance report for the exact minor.

The three-way comparison, with honest numbers​

Public Gateway API benchmarks agree on ordering but disagree on magnitude, which is exactly why methodology matters. One community gateway-api-bench run reports roughly 34k qps for Envoy Gateway, 20k for Cilium, and ~1.7k for NGINX Gateway Fabric at 30 connections with zero errors — while a Gardener evaluation notes ~325k vs ~91k qps for Envoy-class vs NGINX-class implementations in a different harness. Different hardware, different profiles, different dates — same ranking.

Do not pick a gateway on these numbers. They measure a single hot path with no tenant isolation, no certificate churn, no route-table scale, and no noisy-neighbor policy enforcement — the opposite of the PaaS workload defined above. The honest reading:

• Envoy Gateway is the throughput leader and the fastest tracker of new Gateway API Standard features, with the richest policy surface (ClientTrafficPolicy, BackendTrafficPolicy, SecurityPolicy, EnvoyPatchPolicy). Cost: a heavier control plane and a new operational model if your team thinks in NGINX directives.
• NGINX Gateway Fabric is the slowest in synthetic throughput and the slowest to certify each new Gateway API minor — but the cheapest migration from ingress-nginx, with annotation mappings, a migration guide, and a data plane your team already debugs at 3 a.m. without docs. For the defined PaaS workload, config-churn safety and migration cost swamp per-route qps.
• Cilium Gateway collapses L3/L4 and L7 into one eBPF stack with excellent observability (Hubble) when you already run Cilium CNI. Cost: fate-sharing. Gateway and CNI now upgrade together, and a bad Cilium rollout can take down pod networking and north/south ingress in one event. Adopt it because you want the unified stack, not just a gateway.

Extension models sharpen the difference. Envoy Gateway exposes typed policy CRDs plus patch-level escape hatches. NGF pairs nginx.org annotations with Policy CRDs and snippets for NGINX-native knobs. Cilium leans on CiliumNetworkPolicy plus Gateway API attachment, which is elegant inside a Cilium fleet and awkward outside one.

Why a PaaS operator reads this differently than a single team​

A team consuming gateway resources directly asks "can I express my routes?" A platform that routes every tenant domain through one gateway asks five harder questions:

1. Blast radius. One bad tenant config must not break the data plane for the other 199. F5's "bad config handled gracefully" work and Envoy's xDS-based config rejection both target this; verify with a chaos test (apply a broken route, watch the other routes) rather than trusting release notes.
2. Role separation. Gateway API's GatewayClass/Gateway/HTTPRoute split is a PaaS primitive: platform owns the Gateway and listeners, tenants own HTTPRoutes attached via ReferenceGrant. Ingress annotations never gave you this boundary. Whichever implementation you pick, adopt the split — it is the mechanism that lets tenants self-serve routes without self-serving outages.
3. Certificate and hostname scale. Hundreds of hostnames mean cert-manager plus Gateway API integration is load-bearing. Confirm ListenerSet/hostname handling, wildcard behavior, and certificate rotation load on your implementation at your hostname count before committing.
4. Per-tenant observability. Customizable access-log formats (NGF 2.3 added log-format control and disable flags), per-route metrics, and trace identity that survives the gateway are not nice-to-haves when tenants open tickets saying "my app is slow" and the gateway is the only shared component. Envoy's tracing-policy surface is currently the richest here.
5. Upgrade coupling. An independently-upgradeable gateway (NGF, Envoy Gateway) lets you roll gateway and CNI on separate cadences. Cilium's unified stack trades that independence for integration. On a multi-tenant fleet, independent rollback is worth real money.

There is also a cost nobody benchmarks: annotation sprawl. A decade of nginx.ingress.kubernetes.io annotations encodes business logic in strings no schema validates. Gateway API replaces most of it with typed fields — but only if you actually migrate instead of carrying annotations forward via compatibility shims. F5's 1:1 mappings are a bridge, not a destination. Budget the second migration (annotations to HTTPRoute + Policy) even if the first (ingress-nginx to NGF) is cheap.

The decision guide​

• Pick Envoy Gateway if: you are building the gateway fresh, value fastest Standard-feature tracking and richest policy/tracing surface, and can afford the team to learn Envoy semantics. This is the default for a new multi-tenant gateway in 2026.
• Pick NGINX Gateway Fabric if: you carry a large ingress-nginx annotation estate, your on-call muscle memory is NGINX, or you need the F5-adjacent story (OpenShift certification, WAF on NGF). Accept slower synthetic throughput and a version behind on each Gateway API minor — neither binds the defined PaaS workload — and plan the annotations-to-HTTPRoute second migration explicitly.
• Pick Cilium Gateway if: the fleet already runs Cilium CNI and you want one eBPF stack for pod networking, NetworkPolicy, and ingress with Hubble visibility. Do not adopt Cilium for the gateway alone; the CNI migration dwarfs the gateway decision.

Migration next steps regardless of pick:

• Inventory every ingress-nginx annotation in the fleet and classify each as native HTTPRoute, Policy CRD, or implementation-specific escape hatch. Kill what no tenant uses before migrating it.
• Stand up the new GatewayClass alongside the old ingress, mirror one low-risk tenant, and compare access logs, p99, and certificate behavior before moving hostnames.
• Use ingress2gateway for mechanical conversion, then hand-review anything involving auth, CORS, rewrites, session affinity, or rate limiting — the exact features where annotation semantics differ most.
• Pin the Gateway API CRD channel (standard vs experimental) in git, and gate upgrades on the implementation's published conformance report for that minor.

Outlook​

F5's H1 2026 roadmap does not make NGINX the fastest gateway, and it does not need to. What it does is remove the worst reason to avoid NGINX — the fear that the open-source Kubernetes story is unmaintained — and replaces it with visible boards, twice-yearly posts, migration tooling, and a security story (WAF on NGF) staked on Gateway API. That turns the PaaS gateway choice from "which vendor is still investing?" back into an engineering tradeoff: migration cost vs policy richness vs stack coupling.

With ingress-nginx retired and Gateway API v1.5's Standard surface settled, the window to decide is now. Pick the gateway whose coupling and migration profile fits your fleet, validate it against the 200-tenant workload instead of a single-route benchmark, and ship the Gateway/HTTPRoute role split on day one — your future on-call self will thank you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.