Nginx vs Apache

Apache traditionally handles each connection with its own process or thread. That model is simple and flexible, but under thousands of simultaneous connections the memory and context-switching add up. Apache's event MPM closed most of that gap by handling keep-alive connections asynchronously, so modern Apache is far more efficient than its old reputation suggests. Still, the per-connection lineage shows under heavy concurrency.

Nginx was built event-driven from the start. A small number of worker processes handle many thousands of connections each through an asynchronous event loop, so memory stays flat as concurrency climbs. That is why Nginx became the standard at the edge: serving static files, terminating TLS, and proxying to backends, all while holding a lot of slow connections open cheaply.

Apache lets any directory carry a .htaccess file that overrides configuration for that path. On shared hosting this is essential, because it lets each user change rewrite rules and access controls without touching the main config. The cost is performance: Apache checks for .htaccess files on every request up the directory tree, and it is a common source of confusing behavior.

Nginx has no .htaccess equivalent by design. All configuration lives in central files, and you reload the server to apply changes. That is faster and easier to reason about, but it means you cannot hand a directory to a user and let them reconfigure it. If your workflow or your apps assume .htaccess, that assumption alone can decide the question.

Apache can embed the PHP interpreter directly with mod_php, which is the classic LAMP stack and is genuinely simple to set up: install, drop in your PHP, done. The downside is that every Apache worker carries the PHP interpreter whether it is serving PHP or a static image.

Nginx does not embed PHP. It hands PHP requests to PHP-FPM, a separate process pool, over FastCGI. This is more moving parts but scales better and keeps static serving lean. Modern Apache setups increasingly use PHP-FPM too, with the event MPM, which is the configuration most performance guides now recommend regardless of server.

In a self-hosted setup, the web server is often not hosting an app at all. It sits in front of a dozen containers, terminates HTTPS, and routes by hostname to each service. Nginx is the common choice here, and the wider ecosystem reflects that: Nginx Proxy Manager, the Kubernetes ingress-nginx controller, and countless tutorials assume Nginx at the edge.

Apache can reverse proxy perfectly well with mod_proxy, and if Apache is already your app server, adding proxy rules to it is reasonable. But if the proxy is the whole job, Nginx is the path of least resistance. If you want HTTPS handled automatically with the least config, Caddy is worth a look as a third option, which the Caddy vs Nginx comparison covers.

Run Nginx if you are deploying something new, fronting containers, serving static sites or single-page apps, or you want predictable performance under load with a single central config. It is the safer default for most 2026 self-hosting.

Run Apache if your application expects it (some older PHP apps and control panels do), if you rely on .htaccess, if you want mod_php's plug-and-play simplicity, or if a specific Apache module does exactly what you need. Apache is not a downgrade. It is a different config philosophy that some workloads still fit better.