KoaPanel
IT Try it free
All manual sections

DocumentationPHP versions

PHP versions

Several PHP versions can live on the same server, from 7.4 to 8.5: every site uses its own. The PHP versions page is reserved for administrators.

What the page shows

For every version you see whether it is installed, whether it is the default for new sites, how many sites use it and whether it is offered for new sites. The version included in Ubuntu is marked Ubuntu; the others come from the ondrej/php archive, added automatically at the first installation. On AlmaLinux and Rocky Linux every version comes from the Remi repository, set up by the installation. On Ubuntu 26.04 the ondrej/php archive has no packages yet: for now only PHP 8.5, the one shipped with the system, can be installed, and the other versions are shown as not available.

Installing a version

Press Install and confirm. The installation runs in the background (a few minutes) and you can follow its progress on the page. PHP-FPM, the command line and the most used extensions are installed: mysql, curl, gd, mbstring, xml, zip, intl, bcmath, opcache (plus redis and imagick when available). The panel applies its base settings (memory, upload size, opcache) and starts the service.

The other actions

  • Make default: the version used for new sites.
  • For new sites: if you untick it, the version can no longer be chosen for other sites; those already using it keep working.
  • Remove: uninstalls the version. Possible only if no site uses it and it is not the default: first move the sites to another version.

Site version and packages

On every site page, PHP version offers the installed versions offered for new sites, limited to those allowed by the account's package (Packages): in the package you can select some of them; none selected means all.

Site PHP settings

On every site page, PHP settings lets you change for that site memory (memory_limit, up to 1024 MB), upload size (upload_max_filesize, the form limit follows), maximum time (max_execution_time), form fields (max_input_vars) and error display (display_errors). Leave a field empty to use the default value. The panel checks the configuration and, if something goes wrong, puts back the previous one. See also Sites.

More PHP directives (from 0.72.0), in the same card, adds directives of a safe list, each checked by the panel: time zone (date.timezone), error_reporting, short_open_tag, allow_url_fopen, uploads (file_uploads, max_file_uploads, max_input_time), sessions (session.gc_maxlifetime, session.cookie_secure, session.cookie_samesite…), output_buffering, zlib.output_compression, pcre.* and OPcache. Directives about the server's security (for example open_basedir and disable_functions) can't be changed.

PHP processes

The PHP processes of a site (pm.max_children) are the PHP requests the site serves at the same time: the others wait their turn. The default value is 5 per site.

  • For the whole server: in PHP versions, card PHP processes per site, the administrator chooses the value of the sites that don't have one of their own (from 1 to 200). The panel rewrites the pools of the sites right away. Leave it empty to go back to the value of the configuration file (sites.php_max_children in /etc/panel/agent.yaml).
  • For a site: in the site's PHP settings, the PHP processes field wins over the server value. It's set by the administrator and the reseller, within the limit of the account's package and of the reseller's quota (Packages); the account sees it but can't change it. Leave it empty to use the server value.

In the same card of the site you also choose the processes' mode:

  • ondemand (default): processes start when requests arrive and stop after 10 seconds without any; a site without visits uses no memory;
  • dynamic: some processes are always ready. Processes at start, minimum spare and maximum spare (pm.start_servers, pm.min_spare_servers, pm.max_spare_servers) must stay within the PHP processes; left empty, the panel computes them;
  • static: all the processes stay on.

Requests per process (pm.max_requests, default 500) is the number of requests after which a process is renewed. The panel suggests a number of processes based on the server's RAM (about a quarter of the memory for one site at its peak, 64 MB a process).

When "server reached pm.max_children" shows up in the PHP-FPM log, that is the site used all its processes and the extra requests waited, the site's PHP settings show a warning with how many times it happened in the last 7 days and a button to raise the processes. The list of the sites in this situation is also in PHP versions.

From 0.88.0, at the first start after the update the panel reads the pools of the sites: mode, processes, spare and requests per process changed by hand in the pool file become the settings of the site, so they aren't lost when the pool is rewritten.

Both values are kept by the panel, not in the pool files: KoaPanel updates and rewrites of the pools keep them. A change made by hand in the pool file, instead, is lost. Every extra process can use more memory (see below): raise the value only if the server has it.

PHP extensions

For every installed version, Extensions lists the extensions the panel can manage (for example soap, imap, ldap, gmp, apcu, memcached, pgsql, xdebug) with their state: install or remove them one by one, for every site using that version. The base ones (mysqli, curl, gd, mbstring, xml, zip, intl, opcache) are needed by almost every site and can't be removed; on AlmaLinux and Rocky an extension sharing a package with others isn't removed either.

How much memory PHP uses

Measured on the test server (Ubuntu 24.04, PHP 8.3, WordPress 7) in September 2026:

  • Without the Isolation & limits module there is a single PHP-FPM master process per PHP version (about 15–19 MB in total, shared by all sites) and every site has its own pool in ondemand mode: a process starts only when a request arrives and ends after 10 seconds without requests. A site nobody is visiting uses no PHP memory. While working, a WordPress process takes about 22–27 MB (PSS; 50–60 MB counting the shared parts), one per concurrent request, up to the site's PHP processes (5 if you don't change them).
  • For comparison, in dynamic mode (Ubuntu's default) every site always keeps 1 to 3 processes ready (2 at start): after the first visits that is about 25–80 MB per WordPress site even when nobody visits it, or 0.7–2.4 GB for 30 sites. That is why the panel uses ondemand.
  • With the Isolation & limits module every account has its own PHP-FPM master process, which takes about 10 MB even when idle (measured: 10.2 MB per account, 1.5 GB with 159 accounts). For example 30 accounts on a 2 GB VPS are about 300 MB, plus the sites' processes while they work. With PHP on demand (Isolation & limits) an account's PHP stops after 15 minutes without visits (configurable) and uses no memory when idle.