Hero Image

Which PHP mode? PHP-FPM vs FastCGI vs CGI vs mod_php

Which PHP mode? PHP-FPM vs FastCGI vs CGI vs mod_php

There are multiple ways to execute PHP scripts on a web server. We’re often asked about the difference between these modes, so here it is!

We offer the four most common PHP handlers across our Linux Cloud Hosting range:

  • PHP-FPM
  • FastCGI
  • CGI
  • mod_php

Each of these has its own advantages and disadvantages.

Mod_php, while still available in Apache, it was deprecated by Plesk and you can’t use it.


PHP-FPM

PHP-FPM (FastCGI Process Manager) is the modern, high-performance way to run PHP. It builds on FastCGI by managing a pool of worker processes, allowing better handling of concurrent requests and more intelligent resource usage.

Each request is passed to PHP-FPM via a socket. It supports advanced features such as opcode caching, adaptive spawning, and per-site process limits. PHP-FPM combines the isolation of FastCGI with performance that can exceed mod_php, especially under high load.

Plesk supports PHP-FPM natively and offers both shared and dedicated FPM pools. Dedicated pools provide full isolation per site and dedicated memory for opcache, which improves stability and performance, especially on multi-site servers.

Like FastCGI, PHP-FPM does not support .htaccess PHP directives. Configuration is done via php.ini or Plesk’s PHP settings interface.

Pros

  • High performance, especially for high-traffic or dynamic sites
  • Secure, isolated PHP execution
  • Adaptive process management handles load spikes efficiently
  • Supports opcode caching for faster PHP execution
  • Dedicated pools improve per-site stability and performance

Cons

  • .htaccess PHP directives are not supported
  • Requires tuning for optimal performance on high-load servers
  • Slightly more complex to manage than mod_php

FastCGI

FastCGI was introduced as a middle ground between the mod_php and CGI application. It retains CGI’s security benefits while eliminating its performance limitations.

With FastCGI, requests are passed from the web server to a persistent PHP process via a socket. This allows for better scalability and performance. Apache and PHP can even run on separate servers if needed. In Plesk, FastCGI is executed as the domain FTP user and has long been the default handler for many environments.

Unlike mod_php, static content is served without involving the PHP interpreter. Also, files created via PHP are owned by your user account, so you can edit them via FTP or SSH without changing permissions.

However, FastCGI doesn’t support PHP directives in .htaccess. Instead, settings must be configured via php.ini or the Plesk panel.

Pros

  • Improved security, PHP runs isolated from the web server
  • Efficient static content handling
  • Files created by PHP scripts are user-owned, easing file management
  • Better performance than CGI

Cons

  • .htaccess PHP directives are ignored
  • Introduces process management overhead and tuning complexity
  • Slightly less efficient than PHP-FPM under load

CGI

Executing PHP scripts with a CGI application is the legacy way of running applications on a web server and remains highly inefficient. It was introduced in the 1990s but is rarely used today due to performance limitations.

A benefit of CGI is that it keeps code execution separate from the web server, offering a degree of security isolation. It also means the PHP interpreter is only called when required, allowing static content to be served solely by the web server.

However, every PHP request spawns a new process. This results in significant overhead, especially under load, making CGI impractical for modern websites.

Very few Layershift customers use this mode, and we don’t recommend it.

Pros

  • Better security than mod_php, as PHP execution is isolated from the web server
  • Only runs PHP interpreter when needed

Cons

  • Legacy method with very poor performance
  • Spawns a new PHP process for every request
  • Not recommended for anything beyond very low-traffic sites

mod_php (Apache Module)

Using mod_php to execute PHP scripts on a web server was the most popular method used by our customers for many years and was once the default mode when creating a new webspace.

When using mod_php, the PHP interpreter is embedded in each Apache process that’s spawned on the server. This way every Apache worker is able to handle and execute PHP scripts itself, removing the need to deal with any external processes, unlike CGI, FastCGI, or PHP-FPM. This makes it useful for sites that are ‘PHP heavy’ (such as WordPress, Drupal, Joomla, etc.) because all the requests can be handled directly by Apache.

As the interpreter is started along with Apache, it allows PHP to run very quickly by caching certain information and avoiding repeat tasks on each request.

The downside is that the footprint for each Apache process is larger due to the embedded PHP interpreter. Even when serving static content such as images, text, and style sheets, where no PHP code is needed, the process still contains the PHP interpreter, wasting memory. Additionally, this mode lacks isolation and security features now considered standard.

Pros

  • PHP code executed by Apache
  • No external processes required
  • Very good performance on PHP-heavy sites
  • PHP configuration settings may be customised within .htaccess directives

Cons

  • Makes each Apache process footprint larger, meaning more RAM used
  • Loads PHP interpreter even for non-PHP content
  • Files created by PHP scripts are owned by the web server user, so you may not be able to manage them via FTP later
  • Not suitable for shared hosting environments due to lack of user isolation
  • Less compatible with modern Apache (event or worker MPM), which limits scalability

Which Should I Use?

On smaller sites, it usually comes down to personal preference. That said, in 2026:

  • PHP-FPM is the recommended default for most sites. It provides superior performance, security, and scalability
  • FastCGI is still a solid choice, particularly where .htaccess configuration is not required
  • CGI should only be used in rare edge cases for extremely simple, low-traffic sites

CMS applications like WordPress, Drupal, and Joomla perform best under PHP-FPM. It supports user-level file ownership, works well with FTP, and handles concurrent traffic more gracefully.

This is only an overview of a very complex and in-depth issue. We’ve presented the main considerations to inform your decision, but each site is unique. Please contact our support team at u>support@layershift.com</u if you need further guidance.

For a guide detailing how to change the PHP handler using Plesk, see our accompanying knowledgebase article.


Frequently asked questions

1: Which PHP handler should I use in Plesk?

PHP-FPM is commonly used for modern sites because it handles traffic spikes well and offers good isolation between sites. FastCGI is still used in some environments, while CGI is usually reserved for very low traffic or legacy setups.

2: What is the difference between PHP-FPM and FastCGI?

PHP-FPM manages pools of worker processes to handle traffic more efficiently and cope with spikes, while FastCGI runs persistent PHP processes without advanced pool management. Both avoid embedding PHP in Apache, but PHP-FPM typically performs better on busy servers.

3: Does Plesk support changing PHP handlers?

Yes, Plesk allows you to switch between supported PHP handlers through its interface and adjust PHP settings such as memory limits and versions. You can choose the handler that best fits your workload and server layout.

Other Related Posts:

Why Running Old (End of Life) PHP Is a Real Security Risk

Why Running Old (End of Life) PHP Is a Real Security Risk

Many businesses unknowingly continue running old PHP versions long after a website launches. In many cases, production sites still run exactly as they did on day one, including the PHP version.

Once that PHP version reaches end of life (EOL), it no longer receives security updates, and the security risk increases over time, even if the site still appears to work normally. This is one of the most common causes of avoidable website security issues, and it is usually fixable with a combination of planned upgrades and properly managed hosting.

11th Feb 2026
Block Malicious Traffic with Fail2Ban

Block Malicious Traffic with Fail2Ban

Fail2Ban is still one of the simplest and most effective ways to cut out a huge amount of malicious noise before it ever reaches your applications, and in 2026 it slots neatly into Plesk as an extra hardening layer on top of your existing firewalls. Used properly, it lets you automatically block brute force attempts, exploit scans, and spammy traffic across SSH, Plesk panel, web, and mail services, while keeping genuine users flowing through.​

12th Jan 2026