NGINX Services and Ingress NGINX Migration
Last reviewed by Tyler Eastridge
AceMQ gives platform teams NGINX engineers for the web server, reverse proxy and load balancer tier and the Kubernetes ingress layer: version upgrades across the changes in the 1.29 line, reverse proxy, load balancer and TLS reviews, and a route-by-route plan off Ingress NGINX, the Kubernetes controller the project archived on 24 March 2026. NGINX itself, NGINX Plus and F5's own ingress controller are separate and are not affected by that retirement. AceMQ engineers lead each engagement and partner NGINX specialists do the NGINX-specific work, under one AceMQ contract. It starts with a quote within 1 hour and a written plan before anything changes. AceMQ does not ship NGINX builds.
A senior engineer, not an SDR. No sales sequence attached.
Without moving every reverse proxy into a Kubernetes project it does not needFor production incident cover, see AceMQ NGINX 24/7 support.
Customers
Partners
The Problem
Eight NGINX problems that teams bring to AceMQ, from a cluster still on the retired Ingress NGINX controller to a fleet on builds nginx.org no longer lists as current and a slow upstream that exhausts the connection limit. If one describes your week, that is where the review starts.
A cluster still runs the community Ingress NGINX controller, which gets no releases or security fixes now that the repository is archived, and nobody has an inventory of the Ingress resources behind it
Ingress objects carry snippet annotations and custom directives with no direct Gateway API equivalent, and nobody knows which are still needed
The retirement is being read as a verdict on NGINX itself, so reverse proxies on virtual machines get pulled into a Kubernetes migration they do not need
The fleet runs 1.28 or older builds, while nginx.org's security advisories name fixed versions only in the 1.31 and 1.30 lines
An upgrade across 1.29 changed upstream keepalive and proxy_http_version defaults and Host validation, and the configuration was never retested against them
One slow upstream fills the worker connection limit and takes unrelated sites on the same server down with it
Upstream hostnames are resolved when the configuration loads, so a changed backend address means errors until the next reload
The team is weighing NGINX Plus against open source and has no list of which Plus-only features are in use today
A good fit if you run NGINX as a reverse proxy, load balancer or Kubernetes ingress layer in production, and need an upgrade path, a reviewed configuration or a planned exit from Ingress NGINX.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy NGINX.
How it breaks, and the fix
Each proxied request holds a client connection and an upstream connection, and both count against the connection limit of the worker processes. When one upstream stops answering quickly, its requests pile up, the limit fills, and requests for upstreams that are perfectly healthy start to fail with it.
One slow upstream, shared connection limit
Clients reach three upstreams through one NGINX server
NGINX workersNGINX accepts requests and proxies them to three upstreams. Every request is answered quickly, so connections are released as fast as they are opened and the workers sit well below their limit.
The search upstream slows down. Its requests wait, each holding two connections, until the workers hit worker_connections. NGINX logs that the connections are not enough, and requests for the healthy orders and payments upstreams are blocked behind them.
Timeouts are set to what the service can honestly take, and a per-upstream connection limit caps how many workers the search upstream may hold. It still runs slowly, but orders and payments keep their share of the limit.
The failure is rarely the slow upstream itself. It is that nothing in the configuration separates one upstream's trouble from the rest: one connection limit, default timeouts of a minute and no cap per upstream. The fix is a decision per upstream about how long it may take and how much of the server it may hold, written into the configuration, plus an alert on connection use that fires before the log message does. The same review covers worker file descriptor limits and what happens to long-lived connections on a reload.
Our Services
AceMQ runs five NGINX service lines for NGINX as a web server, reverse proxy, load balancer and Kubernetes ingress layer: Ingress NGINX exit and Gateway API migration, upgrades across the 1.29 changes, reverse proxy and TLS reviews, performance and capacity tuning, and a fixed-scope health check. Any of them can roll into 24/7 support with a 15-minute emergency SLA.
An inventory of what your Ingress resources really use, a destination chosen from it, and a parallel run before any hostname moves.
A route from 1.28 or older to the stable or mainline line, with every changed default found by diffing your configuration before production does.
Server blocks, upstream definitions, certificates and protocol settings read against how traffic actually flows, with the failure modes written down.
Connection limits, buffers, caching and upstream behavior tuned from logs and metrics, not from a copied snippet.
The fixed-scope entry engagement: a written report your own team can act on, with or without AceMQ afterwards.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ NGINX support gives you an AceMQ engineer and a 15-minute first response when a proxy, load balancer or ingress layer is down or failing, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes still come from nginx.org releases and, for NGINX Plus, from F5: AceMQ does not ship its own builds.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ NGINX engagement runs in four stages: a scoping call with a quote within 1 hour, a written inventory, a plan tested beside what runs today, then cutover with your engineers and a handover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: reverse proxies and load balancers by version and build, whether Ingress NGINX is in any cluster, which Gateway API or other controllers are already in use, and who owns each hostname. A quote request is answered within 1 hour.
Scoped per estate
For clusters, the Kubernetes check for Ingress NGINX pods, then every Ingress resource, its annotations, snippets and ConfigMap overrides. For the web tier, nginx -V and a dump of the effective configuration per host. Findings are ranked by production risk and written down before anything changes.
Scoped per estate
A destination chosen from your inventory, a replacement installed beside the old controller on its own external address, and converted routes tested there. For the web tier, an upgrade path that names the defaults that change and a rehearsal on a copy of the configuration.
Scoped per estate
Hostnames move one at a time with a rollback point at each step. You keep the inventory, the converted routes, the test requests and the runbooks.
A senior engineer, not an SDR. No sales sequence attached.
Leaving Ingress NGINX
The Kubernetes project retired Ingress NGINX in March 2026 and archived the repository on 24 March. Clusters keep running, and the project itself says that unless you check, you may not know you are affected. A move takes four steps, in this order.
Find it
Run the Kubernetes check for pods labeled app.kubernetes.io/name=ingress-nginx in every cluster, including clusters nobody owns any more. Then list each Ingress resource with its annotations, snippets, ConfigMap overrides and the team that owns the hostname.
Choose
A Gateway API implementation, F5's NGINX Ingress Controller or another Ingress controller. The Gateway API guide suggests weighing conformance reports, the proxy underneath and what your cloud or CNI already offers. A snippet-heavy estate and a clean one rarely end up in the same place.
Run beside it
Give it its own external address, convert routes with ingress2gateway as a starting point, then review and test each one by hand. The tool reports what it could not translate, and its README says widely used annotations may still be unsupported.
Cut over
Shift DNS or the upstream load balancer host by host, watch error rates and latency at each step, and keep the old controller until its traffic is gone. Then remove it. Nothing is left running on a controller that no longer receives fixes.
Typical engagements
Typical NGINX engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Platform Engineering Team
A typical engagement for a platform team that still runs the retired Ingress NGINX controller: every Ingress resource, annotation and snippet inventoried and mapped route by route to Gateway API resources, with a parallel-run plan.
NGINX
KubernetesGateway APIIngress NGINX
Digital Commerce Platform
Tracing intermittent 502s at the Kong gateway to misconfigured active health checks and stale DNS resolution of upstream service names.
KongKubernetesNGINX
PostgreSQL
DockerMulti-Line Insurance Carrier
Designing a Kong topology for a company consolidating several ad-hoc API entry points, including control plane separation and environment promotion.
KongKubernetesPostgreSQLDockerNGINXPayments Technology Provider
Measuring where request latency is actually spent inside the Kong plugin chain, and which plugins are worth their cost.
Kong
RedisKubernetesNGINXSolutions
AceMQ covers NGINX end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed NGINX on your infrastructure and fully managed NGINX on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running NGINX for you.
Compare the four NGINX support tiersSide by side
No alternative is a drop-in replacement, which the Kubernetes project says plainly. The choice depends on what your Ingress resources use today. Each row below answers one question about the three usual routes.
| Question | Gateway API implementation | F5 NGINX Ingress Controller | Another Ingress controller |
|---|---|---|---|
| When does it fit? | You want the Kubernetes project's recommended direction and can move routes to a new API. Several implementations are listed as conformant on the Gateway API site, among them NGINX Gateway Fabric, Envoy Gateway, Istio, Cilium and Traefik. | You want to stay close to NGINX behavior and keep the Ingress API for now. F5 publishes a guide for replacing an Ingress-NGINX cluster with it. | You already run another controller for part of the estate, or your cloud provider offers one that covers your routes. The Kubernetes documentation lists the options. |
| What changes in the manifests? | Ingress becomes Gateway and HTTPRoute resources. Listeners and TLS move to the Gateway, which is usually owned by a different team than the routes. Annotations are not an extension point. | Annotations change prefix, from nginx.ingress.kubernetes.io to nginx.org on the Ingress path, or move into F5's VirtualServer resources. Many ConfigMap keys are renamed. | Depends on the controller. Expect different annotation names and different defaults. |
| What happens to snippets and custom directives? | There is no snippet annotation. Behavior outside the standard API needs an implementation-specific policy or extension, so each snippet is reviewed for whether it is still needed. | Snippet annotations map to location and server snippets. F5's guide lists four Ingress-NGINX annotations that still have no resource fields and are carried by snippets. | Check per controller. Do not assume snippet support exists. |
| What tooling helps? | ingress2gateway can read ingress-nginx resources and emit standard Gateway API resources. It warns about what it cannot translate and says annotations are not copied. | F5's guide has side-by-side tables for annotations and ConfigMap keys. It names no conversion tool. | Usually the controller's own documentation. |
| How is the cutover run? | Install the new controller beside Ingress NGINX on its own external address, test there, then move hostnames one at a time. | The same parallel install. Canary rules must be listed in the same order Ingress-NGINX evaluates them, header, then cookie, then weight. | The same pattern, with the controller's own testing options. |
| When is it the wrong choice? | When the estate leans on controller-specific behavior nobody has listed, and the team will find the gaps in production. | When the plan is to standardize on Gateway API soon, because the estate would move twice. | When nobody has checked who maintains the controller, since a thin maintainer base is what ended Ingress NGINX. |
| What does AceMQ add? | The inventory, a gap list, converted routes reviewed by hand and a parallel-run plan, then support for the new controller. | The same inventory and annotation mapping, with F5 as the vendor for NGINX Plus entitlements. | The same inventory and a written comparison of the controllers you are considering. |
For the inventory step by step and the sources behind this table, read the Ingress NGINX retirement and Gateway API migration guide.
One partner, not five
NGINX rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on leaving Ingress NGINX and on Kubernetes support, plus the AceMQ services around the ingress layer: Kubernetes, Kong and the monitoring stack.
FAQs
Four answers on NGINX from AceMQ: whether the Ingress NGINX retirement affects NGINX itself, what to replace it with, which release line to run and what AceMQ does not do.
Still have questions about NGINX? Email an Expert
No. Kubernetes retired the community Ingress NGINX controller (the kubernetes/ingress-nginx repository, archived read-only on 24 March 2026). NGINX open source, NGINX Plus and F5's NGINX Ingress Controller are separate products and are not part of that retirement. Existing Ingress NGINX deployments keep working, but receive no releases, bug fixes or security updates.
The Kubernetes project recommends Gateway API or another Ingress controller from its documentation, and says none of the alternatives is a direct drop-in replacement. The right choice comes from your inventory: which annotations and snippets your Ingress resources use, and which destination covers them. AceMQ produces that inventory, tests the converted routes beside the old controller and puts the recommendation in writing.
nginx.org publishes both, and on 4 November 2026 listed mainline 1.31.8 and stable 1.30.6. Its security advisories name fixed versions in both lines. AceMQ's default advice is the stable line for estates that change rarely, and mainline when you need a newer feature, checked against the modules and directives your configuration uses.
AceMQ engineers lead the engagement and are your point of contact, and NGINX specialists from AceMQ's partner network do the NGINX-specific work, under the AceMQ contract. AceMQ is independent of F5. It does not ship NGINX builds, backport fixes to old versions or give F5 licensing advice, and it does not replace an F5 subscription for NGINX Plus.
Yes. AceMQ works on NGINX in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your NGINX environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how NGINX is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your NGINX estate and your Ingress NGINX clusters, tells you what to upgrade, move or leave alone, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email a NGINX Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
