Cloud Parts

NGINX

An event-driven web server and reverse proxy that load-balances, caches and terminates TLS for the apps behind it.

What it is
Load balancers
Type
Open source
Made by
F5, Inc.
License
BSD 2-Clause
Facts checked
5 October 2026
Website Source code

What it is

NGINX is one program that can be a web server, a reverse proxy, a load balancer, a content cache and a TCP/UDP proxy, depending on its config file. A master process reads the configuration and starts a few worker processes, usually one per CPU core. Each worker handles thousands of connections at once with a non-blocking event loop instead of a thread per connection, which keeps memory use low under heavy traffic.

As a load balancer you list backends in an upstream block and proxy_pass to it. The open-source version spreads requests by round robin, least connections, random choice, or a hash of the client IP or any key, and marks a server down after failed requests (passive health checks). Since nginx 1.30 (April 2026) it can also pin a client to one backend with sticky sessions and proxy to backends over HTTP/2. nginx -s reload starts new workers with the new config while old ones finish their in-flight requests, so changes don’t drop connections. Igor Sysoev wrote it, and F5 has owned the company behind it since 2019. The core stays BSD-licensed; NGINX Plus is F5’s commercial build.

Why teams pick it

  • Small, fast and battle-tested: Netcraft’s web server survey ranks it first by number of sites
  • One binary covers static files, reverse proxying, caching, TLS and load balancing
  • Config reloads without dropping connections
  • Permissive BSD licence, with official packages for the major Linux distributions and an official container image

Watch out for

  • Active health checks, the API that adds and removes upstream servers at runtime, and least-time balancing are NGINX Plus only
  • Upstreams are static config: open-source nginx can re-resolve a server’s DNS name (resolve), but adding or removing servers means editing a file and reloading
  • You run, patch and scale it yourself, unlike a managed cloud load balancer
  • The community ingress-nginx Kubernetes controller was retired in March 2026; F5’s NGINX Ingress Controller is a separate project

Alternatives

What all load balancers have in common →
AWS Application Load BalancerAWSAWS’s managed layer-7 load balancer: routes HTTP requests by host, path or header to EC2, containers, IPs or Lambda.Cloudflare Load BalancingCommercialA global load balancer that runs in Cloudflare’s network, health-checks your servers from many data centers and sends each visitor to a healthy pool chosen by failover order, location or measured latency.

How it fits with other technologies

Reverse proxy to three app servers, least connections first · nginx

upstream app {
    least_conn;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.13:8080 backup;
}

server {
    listen 80;
    server_name acme.example;
    location / {
        proxy_pass http://app;
        proxy_set_header Host $host;
    }
}

See it in a real stack

No architecture uses NGINX yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2002–2026

Around the turn of the millennium, the engineer Dan Kegel wrote that “it’s time for web servers to handle ten thousand clients simultaneously”, a challenge that became known as the C10K problem. Many of those clients were slow, on dial-up or ADSL, and held connections open for a long time. The dominant server, Apache, spawned a copy of itself (a process or thread) for each connection, so memory and CPU use climbed with every visitor.

Igor Sysoev, a Russian developer, began writing nginx (“engine x”) in the spring of 2002 to solve that problem, and built it for sites like the Rambler portal. He released it publicly on 4 October 2004 under the two-clause BSD licence. By September 2008 it was serving about 500 million requests a day for Rambler.

Sysoev, Maxim Konovalov and Andrew Alexeev founded Nginx, Inc. in 2011 to sell support and later NGINX Plus, and F5 bought the company for $670 million in 2019. Sysoev left in 2022, a core developer forked it as freenginx in 2024, and the same year the project moved its development to GitHub.

Why it’s built this way

An event loop instead of a thread per connection
Each worker watches thousands of sockets and only does work when one is ready, so an idle keep-alive connection costs a little memory instead of a whole process or thread.
A few single-threaded workers, one per CPU core
With no threads inside a worker there is no locking or context switching between them. The operating system spreads the workers over the cores.
A master process that only manages workers
The master reads the config and starts and stops workers, which lets nginx reload configuration or even upgrade its binary without dropping live connections.

Timeline

  1. 2002

    Igor Sysoev starts writing nginx to tackle the C10K problem

  2. 2004

    First public release on 4 October, under the BSD licence

  3. 2011

    Nginx, Inc. founded to offer commercial support and products

  4. 2019

    F5 acquires Nginx, Inc. for $670 million

  5. 2024

    Core developer Maxim Dounin forks freenginx; development moves to GitHub

  6. 2026

    nginx 1.30 stable adds upstream sticky sessions and HTTP/2 to backends

Sources16 · facts checked 5 October 2026

Improve this page on GitHub