NGINX Support
Last reviewed by Tyler Eastridge
AceMQ provides independent 24/7 support for NGINX open source, NGINX Plus configurations and Kubernetes ingress layers: an AceMQ engineer and a partner NGINX specialist on a live bridge within 15 minutes of a P1, a written root-cause analysis after each one, and version planning against nginx.org. NGINX open source has no vendor SLA, and F5 sells its own NGINX Plus subscriptions, so AceMQ is the escalation path for the estate you run, not a replacement for an F5 entitlement. AceMQ does not ship its own NGINX builds.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ NGINX consulting and services.
Customers
Partners
Incident Triage
Common symptoms in NGINX production environments, and the first thing an engineer checks when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Users see 502 or 504 errors from a proxied service, often after a deploy | The error log line, which separates an upstream that closed the connection, one that timed out and one that refused it. Then the upstream address, the read and connect timeouts, and whether the upstream closes idle keepalive connections sooner than NGINX reuses them. | Timeout and keepalive alignment, or the upstream service itself |
| The error log reports that worker connections are not enough | worker_connections against real concurrency, the file descriptor limit the workers actually have, and which upstream is holding connections open. Each proxied request counts a client connection and an upstream connection. | Connection and descriptor limits, per-upstream caps, then timeouts |
| A reload succeeds, but old workers stay in the process list for hours | Long-lived connections such as WebSockets or streaming responses, which keep an old worker until they close, and whether worker_shutdown_timeout is set. | A deliberate shutdown timeout and client reconnect behavior |
| Behavior changed after upgrading from 1.28 or older | A diff of the effective configuration against the defaults that changed in the 1.29 line: upstream keepalive on by default, proxy_http_version 1.1 and no Connection header from 1.29.7, Host and port validation following RFC 3986 from 1.29.4, and a lone LF in a chunked body treated as an error. | Explicit settings in the configuration, and fixes for clients that relied on the old behavior |
| Browsers or API clients fail the TLS handshake after a certificate change | Certificate chain order, the default server for requests without SNI, protocol and cipher settings, and whether the reload actually ran on every node. | Full chain installed, default server set, reload verified per node |
| Errors continue after a backend changed address, until the next reload | How the upstream is defined. Without the resolve parameter or a resolver, NGINX resolves a hostname when it loads the configuration. The resolve parameter is in open source since 1.27.3 and needs a resolver directive. | Resolver and the resolve parameter, or a design that does not depend on DNS changes |
| Cached pages expire together and the origin is hit by a burst of identical requests | The proxy cache settings: whether cache locking is on, whether stale responses may be served while an entry refreshes, and the validity time of the busiest entries. | proxy_cache_lock and stale-while-updating settings |
| An Ingress change is not applied by the community Ingress NGINX controller | The controller log for a failed configuration test. A bad annotation or snippet can stop the controller from reloading for every Ingress. The controller is also archived, so there will be no fix release. | Correct the snippet, then plan the exit with the hub's migration work |
Typical resolution describes the usual fix for each symptom. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
Proxy returning errors, certificates failing, an ingress layer not routing or a fleet out of connections. An AceMQ engineer and a partner NGINX specialist join a live bridge within 15 minutes, 24/7, to diagnose, not to acknowledge a ticket.
Every P1 closes with a written RCA: what failed, why, the change that fixed it and the setting that prevents a repeat. Delivered as standard, not on request.
Where each proxy sits against the mainline and stable lines on nginx.org, and the path to the line you choose, rehearsed on a copy of the configuration. The detailed upgrade and migration work is on the NGINX services page.
Certificates and renewal, protocol settings, default servers, headers and which modules are compiled in, read against how the proxy is reached from outside.
Worker, descriptor and per-upstream limits, buffers, keepalive and cache behavior traced from logs and metrics rather than guessed at.
Ingress NGINX, F5's NGINX Ingress Controller and Gateway API controllers running in your clusters: reload failures, route conflicts and certificate handling, with the exit from Ingress NGINX planned alongside.
Why AceMQ
The same AceMQ engineer and partner specialist stay on your account. They know your server blocks, upstreams and certificate setup, so a P1 call starts with a hypothesis rather than an interview.
You reach a senior engineer directly by phone, email or Slack. No queue collecting details to relay, and no approval between you and someone who can read an error log and act.
AceMQ does not ship NGINX builds or backport fixes. Fixes come from nginx.org releases and, for NGINX Plus, from F5. For a proxy on a version without a fix, we show what is exposed and plan the upgrade.
Logs, metrics and the effective configuration first, then a change with a rollback point. No directive is changed to see what happens in production.
AceMQ staffs 24/7 across the Americas, EMEA and APAC, so your 3am alert reaches someone in working hours.
NGINX rarely runs alone. One AceMQ contract and SLA can also cover Kubernetes, Kong, the monitoring stack and the databases behind the proxy, with multi-technology discounts.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Version coverage
nginx.org sets the status of each release line, and F5 and the Kubernetes project set theirs. AceMQ supports the lines below 24/7, and plans which version you should be on. Fixes for them come from those parties.
| Line or product | Upstream status | AceMQ coverage |
|---|---|---|
| NGINX 1.31.x (mainline; 1.31.8 is listed) | Current mainline release on nginx.org | 24/7 support |
| NGINX 1.30.x (stable; 1.30.6 is listed) | Current stable release on nginx.org | 24/7 support |
| NGINX 1.28 and older | Listed as legacy versions; nginx.org advisories name fixed versions only in the 1.31 and 1.30 lines | 24/7 support, with an upgrade plan and no backports |
| NGINX Plus | F5 subscription product; support entitlement comes from F5 | Configuration and operations support; the F5 entitlement stays with F5 |
| Community Ingress NGINX controller | Retired by Kubernetes; repository archived read-only on 24 March 2026 | 24/7 support while the exit is planned; no patches |
Sources: the nginx.org download page and security advisories, read on 4 November 2026, and the Kubernetes blog posts of 11 November 2025 and 29 January 2026. The download page prints no release or end-of-life dates, so none are given here.
How to plan the move off Ingress NGINX: Ingress NGINX retirement and Gateway API migration.
Who stands behind NGINX
Three parties are involved when NGINX misbehaves, and a page that blurs them sends buyers into the wrong decision.
Engineers who run, troubleshoot and upgrade NGINX, on-call response, root-cause analysis, version planning and performance diagnosis, under one AceMQ contract and SLA.
The open source releases. Fixes and security advisories come from the mainline and stable lines, and AceMQ does not fork, rebuild or backport them.
NGINX Plus, F5's NGINX Ingress Controller and their support entitlements. AceMQ is independent of F5 and does not give F5 licensing advice.
The Kubernetes project archived Ingress NGINX and will publish no more fixes. AceMQ supports it while the exit on the NGINX services page is planned and executed.
Teams that need NGINX Plus features or F5's own support entitlement should buy those from F5. A single reverse proxy that rarely changes and has no on-call duty may not need a 24/7 contract.
Escalation Path
Every tier reaches a senior NGINX engineer. There is no tier-1 triage layer to get through.
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.
Pricing
AceMQ NGINX support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (on virtual machines, bare metal, Kubernetes or cloud-hosted).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Typical engagements
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Digital Commerce Platform
Tracing intermittent 502s at the Kong gateway to misconfigured active health checks and stale DNS resolution of upstream service names.
Kong
Kubernetes
NGINX
PostgreSQL
DockerPayments Technology Provider
Measuring where request latency is actually spent inside the Kong plugin chain, and which plugins are worth their cost.
Kong
RedisKubernetesNGINXPlatform 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.
NGINXKubernetesGateway APIIngress NGINXMulti-Line Insurance Carrier
Designing a Kong topology for a company consolidating several ad-hoc API entry points, including control plane separation and environment promotion.
KongKubernetesPostgreSQLDockerNGINXSupport options
AceMQ offers NGINX support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and emergency response for proxies and ingress layers your team runs, proactive reviews that find certificate, connection-limit and version problems first, managed NGINX on your own infrastructure, and managed NGINX on AceMQ infrastructure. Open source mainline and stable lines, NGINX Plus configurations and Kubernetes ingress controllers are covered by AceMQ engineers working with partner NGINX specialists. Fixes still come from nginx.org and F5.
You run it, we back you up
Best for: Teams that run NGINX themselves and need a second pair of senior hands when the edge misbehaves at 3am.
You run it, we watch it with you
Best for: Teams that want the expiring certificate or the unsupported build found in a review, not in an outage.
We run it in your cloud or data centre
Best for: Regulated estates that must keep traffic and keys inside their own boundary and want someone else on the rota.
We host it and run it, as a service
Best for: Teams that want NGINX at the edge without an NGINX on-call rota.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs NGINX day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for NGINX
Support is one part of what AceMQ does for NGINX. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
AceMQ NGINX support means 24/7 emergency response with a 15-minute P1 SLA, a written root-cause analysis after every P1, configuration and TLS reviews, connection and performance diagnosis, and version planning against nginx.org, delivered by an AceMQ engineer with a partner NGINX specialist. It does not include NGINX builds or backported fixes, which AceMQ does not produce.
nginx.org says enterprise distributions, commercial support and training are available from F5. F5 sells those as NGINX Plus subscriptions and publishes no price. AceMQ is an independent alternative for the estate you run, including open source builds: 24/7 engineers with a defined P1 response, on your infrastructure or in your cloud account.
No. NGINX Plus is an F5 product, and its support entitlement stays with F5. AceMQ is not an F5 partner, has no access to F5 engineering and gives no F5 licensing advice. Teams use AceMQ alongside F5 or on open source builds, for the configuration, operations and incident work around the proxy.
Yes, with limits. The controller's repository was archived read-only on 24 March 2026, so no further releases, bug fixes or security updates exist, and AceMQ cannot supply them. AceMQ keeps the cluster running, diagnoses incidents, shows what remains exposed and plans the move to Gateway API or another controller.
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
Reactive cover, proactive reviews, or AceMQ running NGINX for you on your infrastructure or ours. A senior engineer scopes it with you, and 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.
