Apache2 vs Nginx

Ask about Apache versus nginx and you'll get the same answer you'd have gotten in 2012: Apache spawns a process per request and falls over under load, nginx is fast but its configuration is cryptic, and you should pick nginx unless you're on shared hosting.

About half of that was true in 2012. Most of it isn't now. Both servers have spent the decade fixing what the other did better, and the real differences are narrower and more interesting than the folklore.

Where they came from

Apache httpd grew out of the NCSA web server in 1995 and became the web's default for most of two decades. It was built to be extended: nearly everything it does is a module, and for years "LAMP" meant Apache was where your PHP ran, inside the server process itself as mod_php.

nginx was written by Igor Sysoev starting in 2002 to solve a specific problem: handling ten thousand simultaneous connections on one machine, the "C10K problem," for the Russian portal Rambler. It was released publicly in 2004. Its design is event-driven from the ground up, with a few worker processes each juggling thousands of connections without blocking. F5 bought the company behind it, Nginx Inc., in 2019 for $670 million.

The performance myth

Apache's reputation comes from the prefork model. One process per connection was the only safe way to run mod_php, because PHP extensions often weren't thread-safe. A thousand slow clients meant a thousand processes, each holding a full copy of PHP in memory. That's the Apache that fell over.

Apache 2.4, released in 2012, made the event MPM stable. It works much like nginx: a small pool of threads, with idle keep-alive connections handed off to a listener so they don't tie up a worker. Pair it with PHP-FPM over FastCGI instead of mod_php, which is how you'd run PHP behind nginx anyway, and a modern Apache uses memory in the same ballpark.

nginx is still faster at the extremes. It serves static files with less overhead and holds huge numbers of idle connections more cheaply. If you're serving a CDN edge or tens of thousands of websocket connections, it matters. For a typical application server where the backend takes 50 milliseconds per request, the web server's overhead is a rounding error. Your database is the bottleneck, not your choice of httpd.

Where Apache still wins

  • .htaccess. Per-directory configuration that users can change without touching the main config or reloading the server. That's why every shared host runs Apache, and why so many PHP applications ship with an .htaccess that assumes it. The price is performance: with AllowOverride on, Apache checks every directory in the path for a .htaccess file on every request. If you control the server, put the rules in the main config and set AllowOverride None.
  • Module depth. mod_security, mod_auth_openidc, mod_perl, mod_wsgi, mod_rewrite's endless tricks. Apache's module ecosystem is older and wider, and modules load at runtime with a config line.
  • Application expectations. Some older or enterprise software, and a lot of hosting control panels, document Apache and only Apache. Translating their rewrite rules into nginx is doable, but every one is a chance to break something subtle.

Where nginx wins

  • Reverse proxy and load balancer. This is what nginx is best at and where most deployments use it: TLS termination in front of application servers, upstream pools with health checks, caching, rate limiting, and websocket proxying, all in a few readable lines.
  • Static files at scale. Less memory per connection, sendfile, and simple caching headers. Front a slow application with nginx serving /static/ directly and the application sees a fraction of the traffic.
  • Predictable configuration. One central configuration, no per-directory overrides, and a location block model that does exactly what it says once you understand its matching order. Learn the matching order first. It's the source of most nginx confusion.
  • Footprint. A handful of worker processes and a few megabytes of memory. It fits on a Raspberry Pi and in a 20 MB container image.

A couple of the old complaints no longer apply. nginx has supported dynamically loaded modules since 2016, so you don't have to recompile to add one. And the configuration is no longer obscure, since the ecosystem of examples is now larger than Apache's.

The fork in the road this year

In February, Maxim Dounin, one of nginx's longest-serving core developers, quit and forked the project as freenginx. His reason was a dispute with F5 over how security issues in experimental code should be handled, and more broadly, who gets to decide. His stated aim is a project run by developers, not a corporation. There was already Angie, a fork started in 2022 by other former nginx developers.

For now, nginx from F5 is fine, widely packaged, and still open source under a BSD-style license. But the people who built it are now spread across three projects, and F5 sells a commercial version, NGINX Plus, with features the open source edition doesn't get, like active health checks and a live API. If that sounds familiar, it should. Watch where development actually happens over the next couple of years.

What I'd run

  • A new deployment: nginx as the front door, terminating TLS and proxying to whatever runs the application. It's the most documented pattern on the internet for a reason.
  • PHP applications: either server with PHP-FPM. Never prefork with mod_php for anything new.
  • Shared hosting or an app that depends on .htaccess: Apache with the event MPM, and leave it alone. It works.
  • An old Apache box that isn't broken: don't migrate it for performance. You won't notice the difference, and you'll spend a week relearning a hundred rewrite rules.
  • A small site where you want HTTPS without thinking about it: look at Caddy too. It gets and renews certificates by itself, and its configuration file is short enough to read in one sitting.

The honest answer is that it rarely matters as much as the internet thinks. Pick the one your team already knows how to debug at 3 a.m.

Since then

Added October 2026. One nginx project did reach the end of its road, though not the server itself. In November 2025 Kubernetes announced it was retiring ingress-nginx, the community ingress controller that runs in front of something like half of all clusters, for lack of maintainers. It stopped receiving updates in March 2026, and the project now points people to the Gateway API. nginx is everywhere. The volunteers keeping its wrappers alive weren't.