Apache or Nginx + PHP-FPM: Which PHP Mode to Choose for Your Hosted Website

In a hosting control panel, next to the PHP version, there is often one more setting — the PHP mode: “Apache module” or “FastCGI (Nginx + PHP-FPM)”. Both options work, and your site will open in either of them. But the choice determines whether the rules in your .htaccess file will work, how the site behaves under load and what you will have to configure during a migration.

We explain the difference without unnecessary theory: how each mode works, what happens to .htaccess, when to enable the PageSpeed module and what to choose for WordPress, Joomla, Drupal, PrestaShop, OpenCart and 1C-Bitrix.

Short answer

If your site relies on .htaccess — and most CMSs do — the Apache module is the safest choice during a migration: friendly URLs, redirects and folder protection keep working as before. Nginx + PHP-FPM uses fewer resources per request and handles traffic spikes more steadily, but it ignores .htaccess: the rules have to be moved into the Nginx configuration.

The practical approach: migrate in Apache mode, make sure everything works, and then, if needed, switch to Nginx + PHP-FPM after moving the rules and checking the redirects.

How each mode works

Apache module

PHP runs inside the Apache web server as one of its modules. On most modern hosting, Nginx sits in front of Apache: it serves static files itself — images, CSS, JavaScript — and passes PHP requests on to Apache. Apache reads the .htaccess files in the site’s folders on every request, so you can change any rule just by editing the file.

FastCGI: Nginx + PHP-FPM

Nginx handles every request itself, and PHP code is executed by a separate pool of PHP-FPM processes via the FastCGI protocol. There is no Apache in this setup at all, so nothing reads .htaccess: routing rules, redirects and access restrictions are defined in the Nginx configuration. On the plus side, each request is cheaper to serve, and the server behaves more predictably under load.

The two modes compared

What .htaccess does and what stops working on Nginx

The .htaccess file is a set of instructions for Apache that a CMS usually places in the site’s root folder. On Nginx, the following stop working unless they are moved over:

• friendly URLs — the rule that passes all the “pretty” addresses to index.php. Without it, inner pages return a 404;
• redirects — from http to https, from www to the non-www address, from old URLs to new ones;
• protection for system files and folders — configuration files, logs and backups that must not be accessible from a browser;
• password protection for the admin area or a test copy via .htpasswd;
• headers for caching and security, plus compression;
• PHP directives such as php_value memory_limit — in PHP-FPM mode, these are set in the control panel or in .user.ini.

After any change of mode, check your redirects — the redirect checker makes this easy — and your security headers with the security headers check.

What Nginx rules look like

For most CMSs, the basic friendly-URL rule in Nginx is a single directive. For WordPress and Joomla, it looks like this:

location / {
    try_files $uri $uri/ /index.php?$args;
}

For Drupal, it is almost the same, but without the directory check ($uri/):

location / {
    try_files $uri /index.php?$query_string;
}

For 1C-Bitrix, requests that don’t match any file are passed to /bitrix/urlrewrite.php (simplified):

location / {
    try_files $uri $uri/ @bitrix;
}
location @bitrix {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php;
    fastcgi_pass php-fpm;
}

And here is how to deny access to hidden system files, except for the .well-known folder used for SSL certificates:

location ~ /\.(?!well-known) {
    deny all;
}

PrestaShop and OpenCart have longer sets of rules — for product images, friendly category URLs and protecting system folders — and the exact rules depend on the version and modules. On shared hosting, the Nginx configuration is usually changed by the support team: on our hosting, we set up these rules for your site ourselves.

The PageSpeed module: when to enable it

PageSpeed is a web server module that optimises pages on the fly: it minifies and combines CSS and JavaScript, recompresses images, and can convert them to WebP and add lazy loading. For an older site without a modern front-end build, it is a quick way to make pages lighter without changing the code.

But there are caveats:

• the first requests after changes are slower while the module prepares optimised versions of the files;
• it can conflict with optimisation plugins in the CMS itself: double minification and combining often break scripts;
• some themes and page builders start throwing errors once JavaScript has been combined;
• the module itself has not had major updates for a long time, so enable it selectively and only after testing.

The right order is: measure the speed beforehand, enable PageSpeed on a copy or at a quiet time, check pages and forms, and measure again — with our speed audit or using the method from our article on TTFB and Core Web Vitals. Keep the module only if the result is better.

OPcache works in both modes

OPcache bytecode caching does not depend on the mode: both the Apache module and PHP-FPM keep compiled PHP code in memory, so the CMS does not recompile its files on every request. Make sure OPcache is enabled for your PHP version — it is one of the cheapest ways to cut server response time.

What to choose for your CMS

On our hosting, the PHP mode is chosen for each site separately, along with the PHP version from 5.6 to 8.5. Specific platforms have their own pages: WordPress, Joomla, Drupal, PrestaShop, 1C-Bitrix and Laravel and PHP.

How to change the PHP mode safely

1. Back up your files and database.
2. Find every .htaccess file on the site — not just in the root, but in subfolders too.
3. Move the rules into the Nginx configuration, and the PHP directives into the panel settings or .user.ini.
4. Switch the mode on a copy of the site or during your lowest-traffic hours.
5. Check inner pages, the http and www redirects, the admin area, forms, the cart and protected folders.
6. If something is wrong, switch back to the previous mode — on hosting that lets you choose the mode, this takes a minute — and only then look for the cause.

Conclusion

The Apache module is the most compatible mode: .htaccess rules work, and the migration goes without surprises. Nginx + PHP-FPM is faster and more economical, but it requires moving the rules into its configuration. PageSpeed is a useful tool for older sites, provided you enable it carefully and measure the result. And to find the right PHP version for your CMS, see our PHP compatibility table.

If you would rather not deal with Nginx rules yourself, contact BB STUDIO: we will move your site to our hosting free of charge, choose the mode and set up the rules for your site.