KoaPanel
IT Try it free
All manual sections

DocumentationIsolation & limits

Isolation & limits

Isolation & limits is an optional module that does what CloudLinux does on other panels: every account has CPU, memory, process, disk and database connection limits, and its PHP is isolated from the other accounts. It is included in every plan, with no extra license and no modified kernel: it uses what Ubuntu 24.04 and 26.04, AlmaLinux 9 and Rocky Linux 9 already have (systemd and cgroup v2). On AlmaLinux and Rocky SELinux stays on: the panel adds the few rules the module needs.

The module is not installed by default: until you install it nothing changes on the server. With a few sites you usually don't need it; it becomes useful when the same server hosts the sites of several accounts.

Install and uninstall

From Server › Isolation & limits (administrators): the page first checks the server requirements, then Install. The PHP of each account moves to a service of its own; sites stay online (the PHP of each account pauses for about two tenths of a second). With the installer: KOAPANEL_ISOLATION=1.

Uninstall brings the server back as it was: every site goes back to the shared PHP of its version and the limits no longer apply.

The module has its own version, separate from the panel's: you find it at the top of its page, with the list of versions and what each one brought (for example 1.1.0 came with KoaPanel 0.28.0).

Each account uses about 10 MB of extra memory for its PHP (with 150 accounts, about 1.5 GB); with PHP on demand only the recently visited accounts do. Installing or uninstalling the module on a server with 150 accounts takes a couple of minutes, and the sites stay online.

PHP on demand

On servers with many rarely visited accounts, turn on PHP on demand (module page): the PHP of an account starts at the first visit and stops after 15 minutes without requests (you can change it), freeing its memory. The first page after a pause waits for the start, usually less than a tenth of a second; meanwhile the requests wait in a queue, none is lost. After a server restart too, the PHP of the accounts starts only when needed. Turning it on or off stops the PHP of every account for a moment.

The limits

Limit What it means
CPU (%) 100 = one full core. Beyond it, the account's PHP slows down
Memory (MB) when the account reaches the limit the process that overdoes it is stopped (its page returns an error), the others carry on
Processes processes and threads together: PHP, cron, WP-CLI
I/O (MB/s) read and write on each disk of the sites
Disk operations (IOPS) reads and writes per second on each disk: slows down whoever makes many small operations (file caches, sessions) even without moving many MB
Concurrent PHP requests how many PHP pages of the account are served at the same moment, for all its sites (CloudLinux's entry processes); the others wait their turn instead of taking the server's CPU and memory. It counts PHP processes: if one site of the account keeps many busy, its other sites may wait a few seconds. It applies to each PHP version the account uses
Database connections simultaneous connections of each MariaDB user of the account's sites
Database CPU (%) with the database limiter on: how much MariaDB works for the account (100 = one core, average of a minute). Over it, for 5 minutes each database user of the account can open only 2 connections: the database slows down for that account and not for the others (like CloudLinux's MySQL Governor)
Longest query (s) with the database limiter on: a query that lasts longer is stopped, and the site gets an error for that page
Emails per hour with the mail limit on: emails the account can send in an hour, from the PHP of its sites (mail(), contact forms, WooCommerce) and from its mailboxes together. Over the limit the account cannot send until its last hour is back under it: emails already queued leave, new ones are refused (default 300)
Files (folders included) a soft limit, like the disk space: the count is updated every 15 minutes, at 90% the holder and the reseller get an email, over the limit no new sites can be created. Existing sites keep working

0 means unlimited. The limits of an account are decided like this, from the first one set:

  1. on the account (for example from the options of the WHMCS module, or from Limits & usage › Change the limits);
  2. in its package (Packages, Resources section);
  3. the server default limits (module page): 1 core, 1 GB, 200 processes, 50 MB/s, 1024 IOPS, 20 concurrent PHP requests, 20 connections, 100% database CPU, unlimited queries and files.

If the module was installed before version 0.28, IOPS and concurrent PHP requests stay unlimited until you set them: the update does not change the limits of the sites. An integration that sends only some limits (for example the WHMCS module 1.2) leaves the others as they are.

All these limits (memory, I/O, CPU and the others) are kept by the panel, not in the systemd or PHP-FPM files, which the panel rewrites from these values. KoaPanel updates keep them: from 0.88.0 the default limits in use are saved in the panel, so even if a new version changes its starting values, those of your server stay as they are. A change made by hand in the unit files, instead, is lost.

Administrators' sites have no limits. Only the server administrator sets limits; resellers see them.

Reseller limits

The administrator can give a reseller overall limits (CPU, memory, processes, disk and IOPS) for all its accounts together, from Limits & usage › Resellers › Change the limits. They add to those of each account: if a reseller's accounts together reach the cap, only they slow down, and the accounts of other resellers and of the administrator do not notice. Without overall limits only those of the single accounts apply.

A site that goes over its limits slows down only its own account: the others carry on as before.

Isolation

The PHP and the cron jobs of each account see the system read-only, in the sites folder only their own sites (those of other accounts are simply not there), a private /tmp, no /home or /root folder and only their own processes. This adds to the checks the panel already does (a separate user per site, open_basedir, dangerous functions disabled).

The cron jobs of the account's sites, WP-CLI, WordPress updates made by the panel and the Redis cache of each site also count against the account's limits.

The web server follows a symbolic link only if it belongs to the owner of the file it points to (like CloudLinux's SecureLinks): a site cannot publish, through a link, another site's files, for example its wp-config.php. Since 0.78.2 it is on for every server, also without the module; it can be turned off on the module page (Symbolic links protection).

The SFTP sessions of a site have the same CPU, memory, process and disk limits as its account (each session separately), besides seeing only the site folder as before.

Limits & usage

The Limits & usage page shows for each account its CPU, memory, process and disk usage (graphs of the last 24 hours and 30 days) and the times it hit a limit. Administrators see every account, resellers their own accounts, each user its own account.

Administrators also see the Sites without an account at the top: the administrator's own sites, which have no CPU or memory limits and so are not counted in any account (for example a site migrated leaving "Administrator"). Choose the account and press Assign: the site's PHP moves under that account's limits and from then on the site shows in its usage. For a new user, create the account first in Accounts.

When an account hits its limits an email is sent (at most one a day per account) to the administrators and to its reseller, and also to the account holder, with the reseller's brand and a link to Limits & usage. The email to the holder can be turned off on the module page (Emails to users). If it happens often the site has a problem (a plugin, an attack, too much traffic) or it needs a package with more resources.

Live

The Live tab of Limits & usage is like CloudLinux's lvetop: for every account, the usage of the last few seconds, refreshed every 3 seconds while the page is open (Pause stops it). The columns are CPU, memory, processes, PHP (the PHP requests being served right then, against the limit of simultaneous requests), disk (MB per second read and written) and IOPS; every value has a bar against the account's limit, orange from 70% and red from 90%. The status shows “At the CPU limit”, “At the memory limit” or “At the process limit” when the account got there in those seconds.

By default only the busy accounts are shown; untick Only busy accounts to see them all, search by name or sort by CPU, memory, disk, processes or errors. Administrators see the server at the top (load, CPU, disk wait, memory, fullest disk) and the row of the Sites without an account; resellers also see the total of their accounts.

A click on an account opens its processes with the CPU of the last seconds, the memory, how long they have been running, the site and the command, and the errors of its sites; from there you go to the account's Statistics or to the process manager to stop one.

Site errors

At the bottom of the Live tab are the sites with errors in the last 15 minutes, the last hour or the last 24 hours, read from the nginx logs of every site:

  • Failed pages: the 5xx answers (500 script error, 502 PHP did not answer, 503 service unavailable, 504 timed out, 508 resource limit reached), out of how many requests;
  • PHP busy: PHP refused the request because all the simultaneous requests of the account were in use (or PHP was stopped): the typical error of an account at its limit;
  • Timed out: PHP did not answer in time;
  • PHP out of memory and PHP out of time: a script went over memory_limit or max_execution_time (raise them on the site's page, PHP);
  • other PHP fatal errors.

Every site shows its last error with the time and a Logs button that opens the full logs of the site. The same errors appear under the account when you open it; a site with at least 10 errors in the last 15 minutes also shows up in the alerts of the bar at the top.

Database limiter

It is optional and off by default: turn it on from the module page (Database limiter). When on, the longest query time applies, the database CPU of each account is measured and the graphs include the database too. When the database CPU goes over its limit, the page shows "DB restricted" with the time the connections go back to normal; it counts as a limit hit. To measure it the module turns on MariaDB's per-user statistics (userstat), and turns them off when you turn it off or uninstall the module. The database connection limit applies with the limiter off too.

The Ranking tab orders the accounts over the last 7 or 30 days: first those that hit their limits on the most days, then those using the most CPU. Those that hit them on 3 days or more get the "Bigger package" label.

Every Monday morning the weekly report arrives by email: to the administrators with every account, to each reseller with its accounts. It is sent only if some account hit its limits and can be turned off on the module page.

Resellers also see the usage of all their accounts together against their overall limits.

Mail limit

It is optional and off by default: turn it on from the module page (Mail limit); it needs the Mail module. When on, the panel counts every minute the emails sent by each account and, when it goes over its hourly limit, blocks it: a hacked site sending spam stops there and the server stays off the blocklists. Limits & usage shows "Mail blocked" and a chart of the emails sent; the limits-reached email is sent. The block lifts by itself when the last hour is back under the limit. The Mail module's limit of 200 emails per hour per mailbox still applies.

X-Ray: what slows a site down

Optional and off by default (module page, X-Ray slow sites). When on, for every PHP page lasting longer than the chosen seconds (5 by default) PHP records where it was at that moment. On the account's page in Limits & usage, for each site, you find the culprit (the WordPress plugin or theme, the core, or the file), the slowest functions (database, external calls, waits) and the scripts, with the latest examples. They are kept for 7 days.

Importing the limits from CloudLinux

In the live migration over SSH from a cPanel server on CloudLinux, connected as root, the panel also reads the LVE limits of each account and shows them next to the account. With the module installed, an administrator can tick Import the CloudLinux limits: CPU (SPEED), RAM (PMEM), concurrent PHP requests (EP), processes (NPROC), I/O and IOPS become the limits of the account here. If you bring several accounts into one, the highest limit of each applies (unlimited wins). A CPU speed given in MHz is not imported.

What it doesn't do

No modified kernel and no version selectors for Ruby, Python or Node: it covers PHP and WordPress, i.e. almost all shared hosting.