Nginx vs Apache vs OpenLiteSpeed for WordPress on a VPS

All three web servers run WordPress well. The differences show up in how you configure them, how they cache pages and how much memory they use when traffic rises. This guide compares Nginx, Apache and OpenLiteSpeed on the points that matter on a small VPS, then gives a simple way to choose.

Before you start

This is a decision guide, so there is nothing to install yet. It helps to know:

• Roughly how much RAM your VPS has, and how many sites you plan to host.
• Whether you will use a control panel. Panels often decide the web server for you.
• Whether your themes or plugins rely on .htaccess rules, such as some security or redirect plugins.

How each server handles PHP

WordPress is PHP, and the way each server runs PHP drives most of the other differences.

• Nginx never runs PHP itself. It passes .php requests to PHP-FPM over a socket and serves static files directly. This separation keeps Nginx workers small.
• Apache can run PHP in two ways. The old way is mod_php with the prefork MPM, where every Apache process carries a full PHP interpreter. The modern way is the event MPM with PHP-FPM through proxy_fcgi, which behaves much like Nginx. See Run PHP-FPM with Apache using proxy_fcgi and mpm_event.
• OpenLiteSpeed uses its own LSAPI with LSPHP packages from the LiteSpeed repository. It manages PHP processes for you and is tuned for this setup.

.htaccess support

• Apache: full support. Rules in any .htaccess file apply immediately, as long as AllowOverride permits them. Plugins that write .htaccess rules just work.
• OpenLiteSpeed: reads .htaccess for rewrite rules only, and only after you enable it. Changes are picked up after a graceful restart, not instantly. Other directives, such as php_value or access rules, are ignored. See Make.htaccess rewrites work in OpenLiteSpeed.
• Nginx: no .htaccess at all. All rules live in the server block. For WordPress you need one try_files line for permalinks, and any plugin instructions written for Apache must be translated by hand.

Skipping .htaccess is not only a drawback. Apache has to check for these files in every directory on every request, and Nginx avoids that work.

Page caching

Full-page caching makes the biggest difference to WordPress speed, because cached pages skip PHP and the database.

• OpenLiteSpeed: has a built-in cache that the free LiteSpeed Cache plugin controls. The plugin purges pages automatically when you edit content. This is the easiest strong caching of the three.
• Nginx: has FastCGI cache built in. It is very fast, but you configure cache keys, bypass rules for logged-in users and purging yourself. See WordPress FastCGI cache with Nginx.
• Apache: usually relies on a plugin that writes static HTML files, or on a cache in front, such as Varnish. Apache's own mod_cache works but is rarely used for WordPress.

With any of them, add a persistent object cache such as Redis for busy dynamic pages and admin screens.

Memory use

On a small VPS, memory runs out before CPU does.

• Nginx uses an event-driven model. A few worker processes handle thousands of connections each, so idle and slow clients cost very little. Your RAM mostly goes to PHP-FPM workers and the database.
• Apache with prefork and mod_php is the heaviest option. Each connection holds a full process with PHP loaded, even while it sends a static image or waits on a slow client. Too many visitors can push the server into swap.
• Apache with event and PHP-FPM closes most of that gap. Use this setup if you choose Apache.
• OpenLiteSpeed is event-driven like Nginx and keeps memory use low.

Exact numbers depend on your plugins, PHP settings and traffic. Measure on your own server rather than trusting published benchmarks.

Ease of setup and management

• Apache: the most tutorials and the most predictable behaviour with plugins. Configuration is text files plus .htaccess. It is the default on many control panels.
• Nginx: plain text config with a clear structure. Huge community and many examples. Expect to edit config files for redirects, caching and security rules.
• OpenLiteSpeed: configured mainly through the WebAdmin web console on port 7080. That is friendly at first, but the config files are less pleasant to edit by hand, and fewer guides cover unusual setups.

Which one to choose

• One or a few WordPress sites, and you want strong caching with little effort: OpenLiteSpeed with LiteSpeed Cache. Start with Install OpenLiteSpeed web server on Ubuntu.
• You are comfortable editing config files, host WordPress plus other apps, or plan to reverse-proxy Node.js or Docker services: Nginx with PHP-FPM. Start with Install WordPress on a LEMP stack.
• You depend on plugins that write .htaccess, migrate from shared hosting, or want the widest compatibility: Apache with the event MPM and PHP-FPM. Start with Install WordPress on a LAMP stack.
• You use a control panel: follow the panel's recommended stack. Some panels let you switch servers, and some use Nginx in front of Apache. See Best control panel for WordPress.

There is no wrong answer here. A well-configured server with page caching beats a poorly configured "faster" one every time.

Check your decision

Before committing, test on a staging copy:

1. Restore a backup of your site onto a new VPS with the server you picked.
2. Load the home page, a post, the admin area and the checkout page if you run a shop.
3. Watch memory with free -h and top while you click around or run a small load test.
4. Confirm the cache is serving pages by checking response headers, for example x-litespeed-cache: hit on OpenLiteSpeed or a custom cache header on Nginx.

Troubleshooting

• Permalinks return 404 after a move to Nginx: the server block lacks try_files $uri $uri/ /index.php?$args;. Add it and reload.
• Redirect plugin rules do nothing on Nginx: the plugin wrote .htaccess rules. Switch it to PHP-based redirects or move the rules into the server block.
• .htaccess changes ignored on OpenLiteSpeed: rewrite loading is off, or the server was not restarted after the change.
• Apache uses all the RAM under load: it is probably running prefork with mod_php. Move to event and PHP-FPM, then size MaxRequestWorkers to your memory.

Next steps

• Size the server for your traffic: Choose a VPS size for WordPress.
• Speed up whichever stack you choose: WordPress speed optimisation on a VPS.