Nginx vs Apache for WordPress: Which Should You Choose?

If you are deploying WordPress on your own VPS rather than handing it to a managed host, the web server underneath it is one of the first decisions you have to make. Nginx and Apache are the two options nearly every guide, tutorial, and hosting provider defaults to, and the choice is not cosmetic. They handle incoming requests in fundamentally different ways, and that difference shows up directly in memory usage, concurrency, and how much traffic a given VPS plan can actually serve.

How Apache Handles Requests

Apache's traditional model spins up a separate process or thread for every incoming connection. With the prefork MPM (multi-processing module), that means a dedicated process per connection, each with the full PHP interpreter loaded via mod_php if that is how PHP is configured. Under light traffic this works fine; under heavy concurrent load, each of those processes consumes its own chunk of memory, and a busy WordPress site can end up running dozens of Apache processes simultaneously, each holding a full copy of PHP in memory whether or not it is doing useful work at that instant.

Modern Apache installations mitigate this with the event MPM, which handles connection keep-alive more efficiently, combined with mod_proxy_fcgi to hand PHP execution off to PHP-FPM instead of loading it in-process. This closes much of the historical performance gap with Nginx, but it also means the "Apache is slow" reputation many people repeat is based on a configuration that current Apache does not default to but which cPanel-based shared hosts often still run.

How Nginx Handles Requests

Nginx uses an event-driven, asynchronous architecture: a small number of worker processes, often just one per CPU core, handle thousands of concurrent connections each using non-blocking I/O. There is no per-connection process or thread to spin up, so memory usage stays flat as concurrent connections rise, which is the main reason Nginx became the default recommendation for high-traffic or resource-constrained deployments. PHP execution always goes through PHP-FPM as a separate process pool; there is no equivalent to mod_php baked into Nginx itself.

The trade-off is configuration style. Nginx has no concept of .htaccess: every rewrite rule, redirect, and access restriction lives in the main server block configuration, which requires a config reload to take effect rather than being read fresh on every request. For a self-managed VPS where you control the whole config file, this is a minor inconvenience. For a WordPress plugin that expects to write its own rules into .htaccess automatically, it means those rules simply do not apply and have to be translated into Nginx syntax by hand.

Performance Under Load

On a VPS with a fixed, modest RAM allocation, the memory-per-connection difference is the part that actually matters. A 4GB VPS running Apache with mod_php under a traffic spike can exhaust available memory well before an equivalent Nginx and PHP-FPM setup would, simply because each Apache process is heavier. Nginx serving static assets (images, CSS, cached HTML pages) does so with almost no PHP involvement at all, which is a large share of what a cached WordPress page actually consists of. Apache with the event MPM and PHP-FPM narrows this gap considerably, but Nginx still tends to hold a flatter memory profile under sustained concurrent load, which is exactly the scenario a smaller VPS plan is most exposed to.

Where the difference is smaller than reputation suggests is raw single-request latency for a cached page under light traffic. Both serve a cached static file fast enough that the difference is not perceptible to a human visitor. The performance argument for Nginx is really a concurrency and resource-efficiency argument, not a claim that Apache is slow at rendering any individual page.

Configuration and Flexibility

Apache's .htaccess support is a genuine advantage in specific situations. It lets you change rewrite rules, add redirects, or restrict access to a directory without touching the main server config or reloading anything, which is exactly why shared hosts and cPanel environments are built around it: it lets thousands of tenants each manage their own directory-level rules without an administrator's involvement. Plenty of WordPress security and SEO plugins are written with the assumption that .htaccess exists and write directly to it.

On a VPS you administer yourself, that flexibility matters less, because you already have full access to the main config on either web server. What you gain with Nginx instead is a config file that is checked once and cached in memory, rather than Apache re-checking the directory tree for .htaccess files on every single request, which is itself a small but real performance cost that scales with how many nested directories a request has to pass through.

WordPress-Specific Considerations

Pretty permalinks are the most common point of friction when moving WordPress from Apache to Nginx. On Apache, WordPress writes its own rewrite rules into .htaccess automatically the moment you set a permalink structure. On Nginx, there is no .htaccess to write to, so the standard try_files directive has to be added to the server block by hand, as covered in the WordPress on Nginx deployment guide. It is a one-time, five-line addition, but it catches people off guard the first time a permalink change appears to do nothing.

Some WordPress security plugins that rely on writing IP block rules or access restrictions directly into .htaccess do not have an equivalent automatic mechanism on Nginx; those restrictions need to be handled at the Nginx config level, or with a plugin that supports doing so through PHP rather than through .htaccess rewriting. This is worth checking before migrating a site with a security plugin that has heavily customised .htaccess rules already in place.

What Arcadia Uses and Recommends

Arcadia's own WordPress deployment guide uses Nginx with PHP-FPM and MariaDB, the same stack behind Arcadia's managed WordPress hosting. On the VPS plan sizes most customers run (4GB to 16GB of RAM), the lower memory footprint under concurrent load is worth more than Apache's .htaccess convenience, particularly for anyone running WooCommerce, where concurrent connections during a sale or promotion are exactly the scenario where Apache's per-process memory overhead shows up first.

When Apache Still Makes Sense

Apache remains the right call in a few specific situations: migrating an existing site with extensive, already-working .htaccess rules that would take real effort to translate to Nginx syntax; running a shared hosting-style environment where multiple users need to manage their own directory-level configuration without administrator involvement; or standardising on Apache because a team already has deep operational familiarity with it and the performance difference at the site's actual traffic level is not going to be noticeable either way. None of these are wrong reasons. They are just different priorities than raw concurrency handling on a fixed-resource VPS.

Frequently Asked Questions

Does WordPress run equally well on both?

Functionally, yes. WordPress itself has no dependency on either web server; it runs as PHP, and both Apache and Nginx can execute PHP via PHP-FPM. The differences that matter are operational: memory usage under concurrent load, how rewrite rules and redirects are configured, and how certain plugins expect to interact with .htaccess. A well-configured WordPress site performs well on either server at typical traffic levels; the gap widens as concurrent traffic increases and Apache's default process-per-connection overhead (if mod_php is still in use) becomes the bottleneck before Nginx's does.

Do I need to change anything in WordPress itself when switching web servers?

No changes are needed inside WordPress itself; wp-config.php, the database, themes, and plugins are all web-server agnostic. What changes is the web server configuration around WordPress: permalink rewrite rules need to be added manually to the Nginx server block since there is no .htaccess to write them automatically, and any security or caching plugin that directly edits .htaccess will need its rules reproduced in Nginx syntax instead. Neither change requires touching WordPress's own settings or database.

Can I run Nginx and Apache together?

Yes, and it used to be a common pattern: Nginx sits in front as a reverse proxy handling static files and SSL termination, while Apache runs behind it handling PHP and .htaccess-dependent logic. This gives you Nginx's connection-handling efficiency for the bulk of requests while keeping Apache's .htaccess flexibility for the parts of an application that depend on it. For a straightforward WordPress install it adds a layer of complexity that is rarely worth it; running Nginx directly with PHP-FPM covers the same ground more simply. The combined setup earns its complexity when migrating a legacy application with deep .htaccess dependencies that cannot be easily rewritten.

Which is better for a WooCommerce store specifically?

Nginx has a practical edge for WooCommerce because checkout, cart, and account pages cannot be served from a static page cache the way a blog post can, which means more requests hit PHP-FPM directly, especially during a sale or traffic spike. Nginx's flatter memory profile under concurrent connections gives it more headroom in exactly that scenario. The gap is smaller on a store with modest, steady traffic, where either web server, correctly configured with PHP-FPM and object caching, handles the load without issue.