Choosing the best PHP handler

In this article we’ll discuss the different PHP handler options that you have to choose from on your VPS (Virtual Private Server) or dedicated server running cPanel. A PHP handler defines the method that Apache uses to communicate back and forth with your PHP scripts. Knowing the differences between PHP handlers can help ensure you’re using the best one for your PHP environment.

Choosing the best PHP handler for your specific needs can go a long way in ensuring an efficient and secure PHP hosting experience for all of your websites. One PHP handler is not necessarily better than the others in every situation, so understanding the basics of what each PHP handler has to offer can help you figure out which one might be best in your specific case.

Available PHP handlers

Please keep in mind that with EasyApache 4, FCGI is not included by default. If you would like to use FCGI, feel free to contact our Managed Hosting team.

suPHP (Single user PHP)On InMotion Hosting’s servers, suPHP is the default PHP handler that is used. suPHP runs as a CGI module and its major benefits are stronger security and easy permissions.
DSO (Dynamic Shared Object)Run as an Apache module, DSO also referred to as mod_php, is one of the oldest PHP handlers and its major benefits are speed and the ability to use opcode caching.
FCGI (FastCGI)Run as a CGI module, FCGI also referred to as mod_fcgid, is one of the newest PHP handlers and its major benefits are CPU performance and the ability to use opcode caching.
CGI (Common Gateway Interface)Run as a CGI module, the CGI PHP handler supports some extra configurations, but lacks in both speed and security and is generally not recommended to use.

suPHP – Single user PHP (mod_suphp)

Using the suPHP PHP handler is among the most flexible and secure ways of serving PHP requests. With the suPHP handler selected along with using the suEXEC option, all PHP scripts will be executed as the user that owns the script, instead of running as Apache’s “nobody” user. For every PHP request that is being processed a separate PHP process will be spawned, so it makes it very easy to see and track if one particular user on the server is running a lot of PHP scripts, or which users are causing more CPU intensive PHP script executions.

The main benefit of using the suPHP handler is that it isolates one user on the server from the others. So if one account was compromised because of an exploit in one of your PHP scripts, the attacker would only be able to view or modify files owned by that particular user. It’s also among the easiest to use with CMS (Content Management Systems) such as WordPress or Joomla. As typically these applications require the ability to create files on the server, and being that all of your files are owned by just one user, permission management is easy to configure.

The main disadvantage of using the suPHP handler is that your PHP websites could be slower due to the additional overhead of having to run a separate PHP process per request. Also if your server receives a high volume of PHP requests in a short period of time, this could lead to a heavy load on your server from all of the concurrent PHP processes. Finally you won’t be able to change PHP directives directly from a .htaccess file, you would instead need to make these changes in a php.ini file. For more information on this, you can read our guide how can I make my php.ini file recursive?

You might choose suPHP as your PHP handler if you have multiple users on your server, you don’t want to worry about setting permissions, and you aren’t having any performance issues with the PHP scripts that you currently run.

DSO – Dynamic Shared Object (mod_php)

Using the DSO PHP handler is the fastest way to serve PHP requests. The DSO handler is an older PHP handler that runs PHP as an Apache module. All PHP scripts are executed as the Apache user “nobody”, which allows for faster execution, but can be more of a headache configuring permissions for.

The main benefit of using the DSO handler is that it doesn’t have much overhead, so it’s fast out of the box. You can also use PHP opcode caching along with DSO to speed up your PHP requests even further. Additionally you can set PHP directives directly via .htaccess files to control certain functionality of PHP.

The main disadvantage of using the DSO handler is that all PHP scripts will need to be owned and excuted by Apache’s “nobody” user. This means that PHP executions can’t easily be tracked on a per user basis since they’re all run from the one web server user. Also when you use a CMS (Content Management System) such as WordPress or Joomla that requires the ability of these applications to write or modify files, the proper permissions must be set beforehand to allow this to happen. Each time a new file is created by a PHP script, it will be owned by the “nobody” user and can lead to further permission issues.

Another major drawback of the DSO handler is security. Because all of your users on the server are having their PHP scripts executed by the same “nobody” user, if one of your sites is exploited due to a flaw in one of your PHP scripts, the attacker could potentially look at or modify files outside of that user’s directory that had the PHP script that was exploitable. So when using the DSO handler it’s always very important to keep all of your PHP software up to date with any security patches so they are not exploited.

You might choose DSO as your PHP handler if you only have one user and your primary concern is speed and performance.

FCGI – FastCGI (mod_fcgid)

Please keep in mind that with EasyApache 4, FCGI is not included by default. If you would like to use FCGI, feel free to contact our Managed Hosting team.

Using the FastCGI PHP handler is a faster way to serve PHP requests than using suPHP but typically not as fast as using DSO. FastCGI is good at reducing CPU usage by leveraging your server’s available RAM to keep PHP scripts in memory instead of having to start up a separate PHP process for each and every PHP request.

The main benefit of using the FastCGI handler is that you can use suEXEC just like with suPHP to allow PHP scripts to be executed by the actual user of the PHP script instead of using the Apache “nobody” user. FastCGI also doesn’t require a single PHP process execution per request like suPHP does, so it can be much faster and reduces CPU usage by holding PHP scripts in memory.

The main disadvantage of the FastCGI handler is that it can be very memory intensive. This is because FastCGI keeps PHP sessions opened in the background in memory for quicker access and the ability to use PHP opcode caching can add to the memory usage as well. Additionally FastCGI can encounter an array of errors depending on how your PHP scripts are coded. This can typically require a day or two of setting tweaks, specific to what your PHP scripts are trying to do.

You might choose FastCGI as your PHP handler if you’re experiencing slow or excessive PHP executions when using the suPHP handler, and you have available memory to spare on your server.

CGI – Common Gateway Interface (mod_cgi)

Using the CGI PHP handler is not something widely used anymore due to the other PHP handlers benefits. Like suPHP and FastCGI the CGI handler can use suEXEC so that PHP executions are run by the file owner of a PHP script rather than the Apache “nobody” user.

The main benefit of using the CGI handler is that it is very configurable, and supports using suEXEC for making permissions less of a headache.

The main disadvantage of the CGI handler is that it is the slowest handler. The CGI handler is typically not used much anymore.

You might choose CGI as your PHP handler if for some reason suPHP, DSO, or FastCGI wasn’t available on your server.


You should now have a decent understanding of the different PHP handlers available to use. Choosing which PHP handler is best for your particular PHP environment can be tricky at times, and generally it’s not recommened to change them if you’re not having any performance or security issues with your default setup.

If you’d like a recommendation on which PHP handler might be best in your particluar case we would recommend using the ticket portal in AMP to submit a ticket and our system administration team can review your current server configuration for you.

InMotion Hosting Contributor
InMotion Hosting Contributor Content Writer

InMotion Hosting contributors are highly knowledgeable individuals who create relevant content on new trends and troubleshooting techniques to help you achieve your online goals!

More Articles by InMotion Hosting

11 thoughts on “Choosing the best PHP handler

    1. To check the PHP version of your dedicated server, you can run php -v from the command line. The output will include the details of your PHP version.

  1. Scott,

    I would say installing htscanner is an option here:

    “Allow one to use htaccess-like file to configure PHP

    per directory, just like apache’s htaccess. It is especially useful with fastcgi (ISS5/6/7, lighttpd, etc.).”

    1. Hello Hemm,

      .htaccess works fine with suPHP, but what it says is that you cannot change php directives with the .htaccess file. Those need to be done within the php.ini file. You will get a 500 error if you attempt to change php directives directly within the htaccess file.

      Kindest Regards,
      Scott M

    2. Not sure if this applies but perhaps to iterate on the lack of usability with .htaccess when running suphp; when I was trying to increase the memory limit for wordpress, which can be done multiple ways usually (modifying wp-config.php; .htaccess; php.ini, or contacting the host provider to name a few) the method for .htaccess (which is also how MultiPHP INI Editor applies those settings) dictates adding a line for php7_modules of “php_value memory_limit”; and while this did manage to raise the server’s memory limit to the specified amount, Query Monitor would still indicate the WordPress limit was the previous amount. It was not until I used the method requiring modifying the wp-config.php file was I able to change the WordPress memory limit. Whereas the emphasis is one was a server limit while the other was specific to memory allowed to be used by WordPress.

  2. Just a single read through and the concept becomes clear. Thanks for such a simple and clearly conceptualized article! 🙂

Was this article helpful? Join the conversation!