Nginx

What Nginx actually is

Nginx is software, not a service — one C binary that you install on hardware you already own and configure with a text file. It serves static content, reverse-proxies dynamic applications, caches, terminates TLS, load-balances HTTP/HTTPS and TCP/UDP, and proxies mail. Written by Igor Sysoev beginning in 2002 to attack the C10k problem and publicly released on 4 October 2004, it became the default front end of the internet for a generation of deployments: the P in LEMP, the ingress in a thousand Kubernetes clusters, the thing in front of your Rails app. It is free, open source, and licensed under the 2-clause BSD license.

One correction to the hype before anything else. Our own database entry repeats the familiar line that nginx "powers 33% of all websites" and is the world's most used web server. Both claims are now stale. W3Techs' 23 October 2026 count puts nginx at 30.2% of all websites whose web server is known, in second place — Cloudflare Server overtook it in September 2026 and now sits at 32.6%. That is not a knock on nginx; it says the traffic that once terminated on nginx instances now often terminates at a CDN edge that is itself frequently running nginx-derived software or proxying to it. The honest framing is: nginx is the most widely deployed self-hosted web server and reverse proxy in the world, and one of the top two or three pieces of infrastructure software ever written. We have filed the market-share correction against our listing.

Commercially, nginx has been an F5 property since March 2019, when F5 bought Nginx, Inc. for $670 million. The open-source project continues, but the interesting governance story is the friction: original developer Igor Sysoev left F5 in January 2022, core developer Maxim Dounin forked the project as freenginx in February 2024 citing F5's interference with development, and former nginx developers launched the Angie fork in late 2022. If you bet infrastructure on nginx, that history is worth knowing — the software is stable and boring in the best way, but the stewardship has been contested.

Pricing: what you really pay

The core product costs nothing. Download it, compile it or install a distro package, run it on as many machines as you like. There is no seat count, no request metering, no per-core license. For a load balancer entry on our benchmarks comparisons, this is the ultimate price-performance floor: nginx on a €5 VPS will out-route most paid appliances costing twenty times as much, and we have run exactly that configuration for years.

The money is in the F5 commercial layer. NGINX Plus — the paid subscription — adds advanced load balancing algorithms, active health checks, dynamic configuration via an API, session persistence, JWT authentication, real-time metrics, and 24/7 enterprise support. F5 does not publish NGINX Plus list pricing on its own site; third-party cost trackers put a single-instance subscription somewhere in the range of $849 to $2,099 per instance per year depending on support tier, and actual quotes come from F5 sales. Treat those figures as market estimates, not a price list. Then there is the F5 WAF for NGINX add-on, NGINX Instance Manager, the NGINX Ingress Controller, the NGINX One console, and NGINXaaS for Azure, where pricing is fully published: $0.25/hour fixed per deployment plus $0.008 per NGINX Capacity Unit per hour and $0.005 per GB processed, with each NCU covering 20 Azure Compute Units, 2.2 Mbps of throughput, and 3,000 concurrent connections. Metrics shipping costs roughly $0.03/month and NGINX logging adds about $0.005 per GB of logs.

The practical pattern we see: teams start free, hit the wall on one specific feature — active health checks, live reconfiguration via API, aggregated metrics — then evaluate whether to pay F5, bolt on open-source tooling, or move to HAProxy. Budgeting zero forever is legitimate for most web-serving and simple proxying workloads. Budgeting for Plus is a support-and-features decision, not a capacity decision.

Performance & infrastructure

Nginx's event-driven, asynchronous architecture handles 10,000+ simultaneous connections at roughly 2.5 MB of memory per 10,000 idle keep-alive connections — the reason it displaced Apache in high-concurrency workloads. Feature coverage in current releases is broad: HTTP/1.1 and HTTP/2 including upstream HTTP/2, experimental HTTP/3 since 1.25.0, gRPC proxying, WebSockets with load balancing, TLS with SNI and OCSP stapling, Encrypted Client Hello support in recent builds, ACME certificate issuance and renewal, FastCGI/SCGI/uWSGI backends, and IPv6 compatibility. Binary and configuration upgrades happen without dropping client connections — a genuinely underrated operational property.

Since version 1.9.11 in February 2016, dynamic modules can be loaded without rebuilding the whole binary, though module builds must still match your nginx version and some third-party modules remain static-only. The configuration model is the classic nginx trade: one flat file with nested blocks, extremely expressive in expert hands, and a genuine stumbling block for everyone else. There is no .htaccess-style per-directory override, no hot API for config changes in the open-source edition (that is a Plus feature), and reload semantics reward people who understand exactly what "reload vs restart" does to long-lived connections.

On reliability, the track record is the argument. Two decades of production use, the most common technology deployed in Docker containers per a 2018 survey, and a security track record managed through a predictable patch cadence with stable and mainline branches — mainline 1.31.7 and stable 1.30.6 shipped on 14 October 2026. Nginx does not come with an uptime SLA because it is not a service; you own the SLA. The closest managed offering, NGINXaaS for Azure Standard V3, carries a 99.95% uptime SLA with active-active high availability, autoscaling, and lossless rolling upgrades — the Developer plan has no SLA and no redundancy.

Where it falls short

Configuration complexity is the honest first complaint. Nginx's directive vocabulary is large, error messages from a bad reload are terse, and the difference between "works" and "correctly hardened, right timeouts, right buffer sizes" is a day of reading docs. Beginners will copy a config from a blog and never learn which lines matter.

Second, the open-source edition is deliberately missing things operations teams eventually want: active health checks (open source has passive in-band checks only), a runtime API for configuration changes, centralized metrics across a fleet, and session persistence. Those are Plus features. The freenginx and Angie forks exist partly because of community disagreement over how the project is run, which also means "which nginx?" is now a real question — package-maintainer nginx, nginx.org builds, Angie, or freenginx.

Third, as a load balancer specifically it lacks the discovery integrations and rich traffic management of Envoy or the battle-hardened TCP proxying ergonomics of HAProxy; it is an excellent generalist rather than a specialist's specialist. Fourth, you run it yourself: no vendor takes the pager for your self-hosted instances, and fleet management across hundreds of servers needs either Plus tooling or your own automation. Finally, HTTP/3 support remains experimental in the open-source branch — fine to evaluate, not something we would underwrite an SLA against.

Who should pick this

Our pick for anyone running web applications who wants the industry-standard reverse proxy and HTTP load balancer — from a single-node blog to a multi-tier proxy topology in front of a container platform. It is the default answer in our load balancer category for good reason: it is free, it is documented to death, every operations engineer has touched it, and every problem you will ever hit has been solved on Stack Overflow in 2013.

We would pick HAProxy instead when raw TCP load-balancing policy and health-check sophistication dominate the requirement. We would pick Envoy or a service mesh when gRPC-heavy east-west traffic and deep observability matter more than operational simplicity. And we would buy NGINX Plus when a team needs active health checks, the dynamic API, and vendor support — the product is good, but go in with eyes open that the per-instance subscription math gets expensive at fleet scale.

Key takeaways

• Free, BSD-licensed software: web server, reverse proxy, cache, and HTTP/TCP/UDP load balancer in one binary, publicly released in 2004 and now stewarded by F5
• Market share is 30.2% of websites with a known web server (W3Techs, October 2026) — second behind Cloudflare Server, which overtook it in September 2026
• Event-driven architecture: 10,000+ concurrent connections on minimal memory; HTTP/2, gRPC, WebSockets, IPv6, ACME, experimental HTTP/3
• Open source lacks active health checks, a runtime config API, and fleet metrics — those gate you toward NGINX Plus (est. $849–$2,099 per instance/year) or the freenginx/Angie forks
• No vendor SLA for self-managed installs; NGINXaaS for Azure publishes 99.95% SLA with hourly consumption pricing
• Best default for standard web fronting; pick HAProxy for TCP-centric balancing, Envoy for mesh/gRPC workloads

Sources

• https://en.wikipedia.org/wiki/Nginx
• https://en.wikipedia.org/wiki/F5,_Inc.
• https://w3techs.com/technologies/overview/web_server
• https://w3techs.com/technologies/details/ws-nginx
• https://docs.nginx.com/nginxaas-azure/billing/overview
• https://costbench.com/software/load-balancers/nginx-plus
• https://blog.nginx.org/blog/now-worlds-1-web-server-nginx-looks-forward-to-even-brighter-future