Nginx History & Evolution #

Understanding why a technology was built is often more useful than just learning how to use it. Nginx was born out of real frustration with the limits of existing technology, and the design decisions made two decades ago still shape how Nginx works today. This article traces Nginx’s journey from the personal experiment of a Russian engineer to the infrastructure holding up much of the modern internet.

The Web Before Nginx: Apache’s Dominance #

To understand why Nginx was created, you need to understand the web of the late 1990s and early 2000s. Apache HTTP Server, first released in 1995, was the web server that absolutely dominated the internet. At its peak, Apache controlled more than 70% of all web servers worldwide.

Apache used a model called prefork or worker: each incoming connection is handled by one process (or thread) dedicated entirely to that connection.

flowchart LR
    subgraph Apache["Apache Web Server (Prefork)"]
        direction TB
        C1["Connection 1"] --> W1["Worker Process 1<br/>(Uses ~8 MB RAM)"]
        C2["Connection 2"] --> W2["Worker Process 2<br/>(Uses ~8 MB RAM)"]
        C3["Connection 3"] --> W3["Worker Process 3<br/>(Uses ~8 MB RAM)"]
        C4["Connection N"] --> W4["Worker Process N<br/>(Uses ~8 MB RAM)"]
    end
    
    style Apache stroke:#d32f2f,stroke-width:2px

• RAM Requirement Estimate: 1,000 concurrent connections $\times$ 8 MB per worker process = 8,000 MB (8 GB RAM).

This model worked well while the number of concurrent connections was still in the hundreds. But the internet was growing fast. Websites began getting thousands, then tens of thousands of simultaneous visitors. And that’s where the trouble started.

The C10K Problem: A Turning Point in Web Server History #

In 1999, an engineer named Dan Kegel published a document that would become hugely influential: “The C10K Problem” (C10K = 10,000 Connections).

The question he posed was simple but shocking for its time:

Isn’t it time for web servers to handle ten thousand clients simultaneously?

Kegel documented that with the hardware available back then, handling 10,000 concurrent connections should theoretically be possible. But in practice, no web server could do it reliably — not because of hardware limits, but because of software architecture limits.

flowchart TD
    subgraph Tradisional["Traditional Model (Thread-per-Connection)"]
        direction TB
        Lim1["Server with Limited RAM (e.g., 1 GB)"]
        Lim1 -->|"1 Process = 8MB RAM"| Lim2["Max Limit: ~128 Concurrent Connections"]
        Lim2 -->|"If RAM Limit Is Exceeded"| Lim3["Out Of Memory (OOM) / Crash"]
        Lim2 -->|"High CPU Load"| Lim4["Excessive Context Switching Overhead"]
    end
    
    style Tradisional stroke:#d32f2f,stroke-width:1.5px

Even if RAM were sufficient, the operating system has a hard limit on how many processes can run at once (process limit), and the CPU would waste cycles just constantly switching context (context switching) between processes.

Kegel’s C10K document became something of a manifesto, sparking a wave of research and experiments into new web server architectures. One of the people who read and was influenced by it was Igor Sysoev.

Igor Sysoev and the Birth of Nginx #

Igor Sysoev was a Russian software engineer working at Rambler, a major Russian internet company often described as “Russia’s Yahoo”. In the early 2000s, Rambler operated several very high-traffic sites, and Sysoev wrestled daily with Apache’s limitations.

After reading about the C10K problem, Sysoev decided to try building something different — not by patching Apache, but by redesigning the architecture from scratch.

In 2002, he started writing Nginx as a personal side project. His goal was specific: create a web server that could handle many concurrent connections with very low resource consumption.

The key to his approach was abandoning the one-process-per-connection model in favor of an asynchronous event-driven model. Instead of one process blocking and waiting for a single connection to finish, a single process could manage thousands of connections at once in a non-blocking way.

timeline
    title Early Nginx Timeline
    2002 : Igor Sysoev starts writing Nginx
         : Addressing Apache's limits at Rambler
    2004 : Nginx 0.1.0 released publicly (October)
         : First ran in production at Rambler
    2006 : Starts gaining global attention
         : Adoption beyond the Russian community
    2008 : Nginx 0.6 stable
         : SSL & Proxy Cache features introduced
    2011 : Nginx Inc. founded
         : Igor Sysoev serves as CTO
    2019 : F5 Networks acquires Nginx Inc
         : Acquisition valued at $670 million
    2022 : Igor Sysoev steps down from F5/Nginx
         : Retires after 2 decades of work

First Public Release: October 2004 #

In October 2004, Nginx 0.1.0 was released publicly. By that time, Nginx was already running in production at Rambler, proving it could handle loads that overwhelmed Apache.

That first release was not a polished product with great documentation — it was working code, shared with the community in the hope that someone would contribute. Igor Sysoev, who wrote almost all of Nginx by himself, never imagined the project would grow this big.

flowchart LR
    subgraph Fitur["Nginx 0.1.0 (October 2004)"]
        direction TB
        F1["✓ Basic HTTP/1.1 Web Server"]
        F2["✓ Simple Reverse Proxy"]
        F3["✓ FastCGI (For PHP Execution)"]
        F4["✓ Event-Driven (epoll & kqueue)"]
        
        NF1["✗ No SSL/HTTPS Yet"]
        NF2["✗ No Load Balancing Yet"]
        NF3["✗ No Complex Rewrite Rules Yet"]
    end
    
    style Fitur stroke:#0288d1,stroke-width:2px

Despite its limited features, the technical community — initially mainly in Russia — adopted Nginx quickly for a simple reason: it really was far faster than Apache for certain scenarios.

Global Spread: 2006-2011 #

Between 2006 and 2011, Nginx began spreading beyond the Russian community. Several factors contributed:

• The Web 2.0 startup boom: Twitter, YouTube, Facebook, and thousands of other startups were building platforms with exponentially growing traffic. They needed a web server that could scale, and Nginx started getting noticed among engineers.
• Community blog posts and tutorials: Engineers who successfully replaced Apache with Nginx and saw dramatic drops in CPU and memory usage began writing about their experiences. Stories of “we swapped Apache for Nginx and our servers could finally breathe” circulated widely.
• The rise of the LEMP stack: If LAMP (Linux, Apache, MySQL, PHP) was the traditional stack, LEMP (Linux, Nginx, MySQL, PHP) became a popular alternative. Hosting providers began offering LEMP as an option.

[!NOTE] Data varies depending on the survey methodology. Globally, Nginx overtook Apache’s market share around 2019-2021.

Founding Nginx Inc.: 2011 #

In 2011, Nginx Inc. was founded in San Francisco. Igor Sysoev joined as CTO, while Maxim Konovalov and Gus Robertson (software industry veterans) took on the business and CEO roles.

Founding a commercial company marked an important transition: from an open-source project run by one engineer to a company-backed product with resources for faster development.

Nginx Inc. introduced Nginx Plus — a commercial version with enterprise features like active health checks, a live monitoring dashboard, and official support. Nginx open source remained freely available with no restrictions.

This business strategy — a strong open-source base, with a paid commercial version for enterprises — proved successful and was later copied by many other open-source companies.

flowchart TD
    OS["Nginx Open Source (nginx.org)"] -->|"Free Technology Base"| PL["Nginx Plus (nginx.com)"]
    
    subgraph Komersial["Paid Business (Plus)"]
        PL -->|"Enterprise Features"| F_ENT["Active Health Checks, JWT Auth, Live Dashboard"]
        PL -->|"SLA Technical Support"| F_SUP["Fast F5 Support Team Response"]
    end

    style OS stroke:#0288d1,stroke-width:2px
    style PL stroke:#d32f2f,stroke-width:2px

Ecosystem Growth: Docker, Kubernetes, and the Cloud #

The 2013-2020 era brought a new wave that benefited Nginx: containerization and orchestration.

Docker (2013) made packaging applications as containers mainstream. The official nginx Docker image became one of the most downloaded images on Docker Hub — to this day, the nginx image has been pulled more than a billion times.

Kubernetes (2014) needed an Ingress Controller — the component that handles HTTP routing from outside the cluster to services inside. The Nginx Ingress Controller became the most popular choice and was even considered the de facto default for a long time.

flowchart TD
    subgraph K8S["Kubernetes Cluster"]
        direction TB
        ING["Nginx Ingress Controller"] -->|"Host/Path Routing"| SA["Service A (App Pods)"]
        ING -->|"Host/Path Routing"| SB["Service B (App Pods)"]
    end
    
    Trafik["External Traffic (HTTP/HTTPS)"] --> ING

    style K8S stroke:#388e3c,stroke-width:2px
    style ING stroke:#0288d1,stroke-width:2.5px

The big cloud platforms — AWS, GCP, Azure — all provide Nginx images in their marketplaces and use it across various managed services. AWS even has official tutorials for deploying Nginx on EC2 and ECS.

Acquisition by F5 Networks: 2019 #

In March 2019, F5 Networks announced the acquisition of Nginx Inc. for $670 million — one of the largest acquisitions in the history of open-source infrastructure software.

F5 is a company long active in Application Delivery Controllers (ADC) and enterprise load balancing. Acquiring Nginx gave them:

• A massive footprint in the modern web server market
• Technology to compete in the cloud-native and container space
• An active, loyal open-source community

So far, those promises have largely been kept. Nginx is still actively developed, the open-source version remains free, and the community is still alive.

Igor Sysoev’s Departure: 2022 #

In January 2022, Igor Sysoev announced his resignation from F5/Nginx. In his announcement, he cited health reasons and a desire to focus on things outside of work.

The departure of the creator from the project he built over two decades was met with a mix of respect and concern by the community. Sysoev almost never spoke in public during his career — he was known more for his code than his face — so his exit was relatively quiet yet meaningful.

Nginx kept running without Sysoev. The team built up over the years at Nginx Inc. and F5 continued development. But for many in the community, the corporate-run Nginx feels different from the Nginx created by an engineer frustrated with Apache.

Nginx Today: Numbers and Position #

As of 2024, Nginx is the most widely used web server on the internet by several metrics:

Widely Adopted by: #

• Netflix (Streaming media)
• Airbnb (Marketplace platform management)
• GitHub (Developer hosting)
• Dropbox (Cloud storage)
• WordPress.com (Largest blog hosting)
• DuckDuckGo (Privacy search engine)

Nginx’s market share among the top 1 million websites is far higher than the overall average. This reflects its original purpose: handling very high traffic loads.

Competitors and Industry Response #

Nginx’s success didn’t happen in a vacuum. It triggered a response from Apache and helped give birth to several new web servers and proxies.

Apache Responds: MPM Event #

After watching Nginx’s rise, the Apache community didn’t sit still. Apache 2.4 (2012) introduced MPM Event as a more efficient process model — borrowing some principles from Nginx’s model.

flowchart TD
    Prefork["Prefork MPM (1995)<br/>- Most Stable<br/>- Very Memory-Hungry"] --> Worker["Worker MPM (2002)<br/>- Thread-Based<br/>- Less Compatible with mod_php"]
    Worker --> Event["Event MPM (2012)<br/>- Non-blocking Keep-alive<br/>- Closer to Nginx's Model"]

MPM Event helped Apache stay relevant, but Nginx had already gained momentum that was hard to reverse.

The Birth of Caddy, Traefik, and Envoy #

Nginx’s success also inspired a new generation of web servers and proxies:

• Caddy (2015): Written in Go, Caddy popularized the concept of “automatic HTTPS” — it handles Let’s Encrypt certificates automatically. This addressed one of the biggest pain points of manual SSL configuration.
• Traefik (2015): A cloud-native proxy designed for containers. Traefik automatically detects new Docker/Kubernetes containers and sets up routing without needing a restart.
• Envoy (2016): Developed by Lyft, Envoy is a layer-7 proxy for the Istio service mesh. Far more complex than Nginx, but extremely powerful for giant microservices deployments.

Nginx in Indonesia and Southeast Asia #

Although Nginx was born in Russia and grew fast in Silicon Valley, its adoption in Southeast Asia — including Indonesia — is significant.

Major Indonesian tech startups — Tokopedia, Gojek, Bukalapak, Traveloka — all use (or have used) Nginx as part of their infrastructure. Nginx became the default choice for cloud deployments on AWS, GCP, and Azure, which are popular among Indonesian startups.

Indonesian developer communities are active on forums like Kaskus Tech, and Indonesian Python/Laravel Discord communities often discuss Nginx configuration, especially for deploying Laravel (PHP) and Django (Python) applications.

Controversies and Criticism #

Like any successful technology, Nginx is not without controversy.

Licensing and Open Source Concerns #

Nginx uses the BSD 2-Clause License — one of the most permissive open-source licenses. This means anyone can use, modify, and distribute Nginx — even in closed-source commercial products — without any obligation to share their modifications back.

After the F5 acquisition, some community members worried that new features would be added to Nginx Plus only, leaving the open-source version increasingly behind. So far this concern hasn’t significantly materialized, but it remains a topic of discussion.

Inconsistent Configuration #

One criticism often voiced by new Nginx users is the inconsistency of its configuration syntax. Some directives use different units, some directive names are unintuitive, and certain behaviors can only be learned through experience or careful documentation reading.

# Examples of confusing unit inconsistencies:

# 1. Values in bytes/megabytes
client_max_body_size 10m;   # 'm' for Megabytes

# 2. Values in seconds
keepalive_timeout 65;       # 65 seconds (no unit letter)

# 3. Precise duration values
proxy_read_timeout 60s;     # 60 seconds (must write 's')

This isn’t a fatal problem — you get used to it with experience — but for beginners it can be a source of frustration.

FrankenNGINX and Forks #

After the F5 acquisition, a developer released Freenginx — a fork of Nginx maintained by a former core Nginx developer unhappy with Nginx’s direction under F5. The fork is still relatively new and hasn’t gained significant adoption yet, but its existence shows the tension within the post-acquisition community.

Igor Sysoev’s Legacy #

It’s hard to talk about Nginx’s history without appreciating Igor Sysoev’s contribution. He wrote nearly the entire early Nginx codebase by himself — a remarkable achievement given how complex and critical the software he created is.

Sysoev was known as a meticulous, perfectionist programmer. Nginx’s code is famously clean and well-documented (initially in Russian, later translated). He rarely gave interviews or spoke at conferences — he preferred to let his code speak.

In one of his rare interviews, Sysoev said he started Nginx with no intention of creating a big project — he just wanted to solve the problem he faced every day. It’s a good reminder that much of the world’s most influential software was born from practical frustration, not grand visions.

Lessons from Nginx’s History #

Nginx’s history holds several lessons relevant not just to technical understanding but also to how you think about software engineering:

• Clear problems demand bold solutions: Sysoev didn’t try to fix Apache — he rewrote from scratch because he realized the problem was architectural, not superficial.
• Side projects can change industries: Nginx started as a personal experiment never intended to become a commercial product. It reminds us that innovation often comes from curiosity and frustration, not business plans.
• Good design endures: The architectural decisions Sysoev made in 2002 — the event-driven model, non-blocking I/O, single worker processes — are still Nginx’s core two decades later. Good design doesn’t need frequent replacement.
• Open source as leverage: The decision to release Nginx as open source enabled massive adoption, which then became the foundation of a commercial business worth hundreds of millions of dollars.

Nginx in the Context of Web Technology History #

To place Nginx in a broader perspective, let’s look at how it fits into the evolution timeline of the web:

timeline
    title Web Technology Evolution Timeline
    1991 : First Web Server (CERN httpd) by Tim Berners-Lee
    1995 : Apache HTTP Server 1.0 released
    1999 : Dan Kegel publishes "The C10K Problem"
    2002 : Igor Sysoev starts writing Nginx privately
    2004 : Nginx 0.1.0 released publicly to the world
    2009 : Ryan Dahl introduces Node.js (async event loop philosophy)
    2011 : Nginx Inc founded in San Francisco
    2013 : Docker popularizes container technology
    2014 : Kubernetes launched by Google
    2019 : F5 Networks acquires Nginx for $670 million
    2022 : Igor Sysoev steps down from Nginx/F5

Nginx is a child of the C10K problem, born in the Web 2.0 era and grown into the infrastructure underpinning the Cloud Native era.

Important Nginx Versions #

Nginx has two branches: mainline (odd versions, like 1.25) which gets new features, and stable (even versions, like 1.24) which is more conservative. For production, the stable branch is generally recommended.

timeline
    title Nginx Milestone Versions
    2004 : 0.1.0 - First public release
    2008 : 0.7.x - SSL & Proxy Cache features stabilize
    2011 : 1.0.0 - First major version released
    2013 : 1.4.x - WebSocket proxying support
    2015 : 1.9.5 - Official HTTP/2 multiplexing support
    2016 : 1.9.11 - Dynamic modules loading
    2017 : 1.13.x - gRPC proxying support
    2023 : 1.25.x - HTTP/3 & QUIC integration

The most game-changing feature: HTTP/2 in version 1.9.5 (2015), which enabled multiplexing — many requests over a single TCP connection, eliminating HTTP/1.1 head-of-line blocking.

Community Contributions and Ecosystem #

Although the Nginx core is developed by a small team, the ecosystem around it is built by a very active community:

• OpenResty: An Nginx distribution integrated with LuaJIT, allowing complex application logic to be written directly in Nginx configuration using Lua. Widely used in API gateways, WAFs, and platforms like Cloudflare.
• Nginx Ingress Controller: The most popular Kubernetes project for routing HTTP traffic to services inside the cluster. Managed by the Kubernetes community.
• ModSecurity-nginx: A port of the popular ModSecurity WAF for Nginx, enabling filtering of malicious requests based on rulesets like OWASP CRS.

flowchart TD
    Core["Nginx Core Engine"] --> OR["OpenResty (Lua Engine)"]
    Core --> ING["Nginx Ingress Controller (Kubernetes)"]
    Core --> MS["ModSecurity (WAF Filter)"]

    OR --> Kong["Kong API Gateway"]
    ING --> Cert["Cert Manager / TLS"]
    MS --> OWASP["OWASP Core Rule Set"]

    style Core stroke:#0288d1,stroke-width:3px

This ecosystem shows that Nginx is more than a web server — it’s a platform that serves as the foundation for various higher-level infrastructure solutions.

Looking Ahead: Nginx’s Direction #

Although Nginx is already very mature, development continues. Several areas are currently evolving:

• HTTP/3 and QUIC: Nginx supports HTTP/3 in the mainline branch. HTTP/3 uses UDP via QUIC, addressing TCP’s fundamental weaknesses around packet loss and connection migration. This matters for mobile users who frequently switch networks.
• Deeper Kubernetes integration: The Nginx Ingress Controller keeps evolving with features like more powerful custom snippets, cert-manager integration, and better Gateway API support.
• OpenTelemetry: Nginx is integrating OpenTelemetry natively for distributed tracing — the ability to trace a request from Nginx all the way to the backend, invaluable for debugging microservices architectures.
• NGINX Unit: A multi-language application server (PHP, Python, Ruby, Go, JavaScript) that can be configured dynamically via API. It’s different from regular Nginx but shows where F5 wants to take the Nginx portfolio.

flowchart TD
    subgraph F5["Modern NGINX Products & Integrations"]
        direction TB
        subgraph CoreProduct["Core Engines"]
            C_OSS["Nginx Open Source"]
            C_PLS["Nginx Plus"]
            C_UNT["Nginx Unit (App Server)"]
        end

        subgraph Integrations["Integrations & Observability"]
            I_OT["OpenTelemetry Tracing"]
            I_H3["HTTP/3 & QUIC Protocol"]
            I_GW["Kubernetes Gateway API"]
        end
    end

    style F5 stroke:#388e3c,stroke-width:2px

Summary #

• Nginx was born from the C10K problem — the challenge of handling 10,000 concurrent connections that Apache’s traditional architecture couldn’t solve.
• Igor Sysoev created Nginx as a personal side project in 2002, released publicly in October 2004.
• The event-driven model was Sysoev’s answer to Apache’s one-process-per-connection limitations.
• Nginx overtook Apache in market share around 2019-2021, and now dominates especially among large sites.
• Nginx Inc. was founded in 2011, acquired by F5 Networks in 2019 for $670 million.
• Igor Sysoev resigned from F5/Nginx in January 2022.
• The Nginx ecosystem includes OpenResty, the Nginx Ingress Controller, ModSecurity, and many other community projects.
• Today, Nginx is used by the majority of high-traffic websites and has become the default choice for cloud-native infrastructure.

← Previous: What is Nginx?   Next: Nginx vs Apache →