cwpsapi is CWP’s own PHP handler. It runs PHP through persistent lsphp workers instead of forking a fresh php-cgi process on every request (the way suPHP does), so it is many times faster while keeping the same per-account security model: each site’s PHP runs as that account’s own Linux user, never as root and never as the web-server user. It also offers an optional built-in full-page cache (LSAPI-Cache).
In CWP’s own benchmarks a simple request is served in about 4 ms under cwpsapi versus about 168 ms under suPHP (roughly 40× faster per request), and under concurrency cwpsapi scales cleanly with zero failures. With LSAPI-Cache warm, cached pages are served in under 5 ms at thousands of requests per second.
Note: cwpsapi is a CWPpro feature and is available in CWP 2.0 and later. The account’s PHP must be running on the suPHP handler before you switch it to cwpsapi.
Where to find it
Log in to the CWP admin panel and open WebServers → cwpsapi (LSAPI PHP + Cache). From the command line everything is driven by /scripts/cwp_cwpsapi.
Which PHP version runs
Like PHP-FPM, cwpsapi serves one PHP version per account. When you enable it, cwpsapi auto-detects the version the account already chose in the PHP Selector (from the account’s .htaccess) and pins lsphp to that version. If you later change the version in the PHP Selector, run cwp_cwpsapi sync (the panel does this for you) to re-pin every enabled account to its current version.
Note: Per-directory version switching (different PHP versions in different folders of the same account) is a suPHP-only feature. cwpsapi and PHP-FPM are one version per account.
Activate lsphp for an account
From the panel (GUI)
- Open WebServers → cwpsapi (LSAPI PHP + Cache).
- Find the account in the list. Each row shows its current PHP version and its CWP Cage status.
- Optionally tick cache to turn on LSAPI-Cache for that account.
- Click Enable. The account’s
.phprequests are switched to the cwpsapi handler without regenerating the vhost.
You can also set cwpsapi as the server default for new accounts from the same page.
From the command line (CLI)
# Enable cwpsapi for one account (auto-detects its PHP version)
/scripts/cwp_cwpsapi enable <account>
# Pin a specific version and turn on LSAPI-Cache
/scripts/cwp_cwpsapi enable <account> 83 --cache
# Status / list / disable
/scripts/cwp_cwpsapi status <account>
/scripts/cwp_cwpsapi list
/scripts/cwp_cwpsapi disable <account>
# Move every suPHP account to lsphp in one reload (optionally caged)
/scripts/cwp_cwpsapi convert-suphp --cache --cage
# Re-pin all accounts to their current PHP Selector version
/scripts/cwp_cwpsapi sync
# Re-apply all overrides after a WebServers rebuild
/scripts/cwp_cwpsapi rebuild
Tip: Recommended order to move a site to cwpsapi: in WebServers set the domain’s PHP to suPHP, enable CWP Cage for the account, then enable cwpsapi. An account whose domains are on PHP-FPM is refused unless you pass --force.
PHP settings: which php.ini is loaded
cwpsapi reads PHP settings from two places, in this order:
| Layer | File | When it applies |
|---|---|---|
| Global (per version) | /opt/alt/php<NN>/usr/php/php.ini plus the scan dir /opt/alt/php<NN>/usr/php/php.d/*.ini | Always. The scan dir (ioncube, imagick, sodium…) loads for every request. |
| Per-account (optional) | /home/<user>/php.ini | When the file exists, cwpsapi sets PHPRC to the account home and reads it as the main ini. When it is absent, the global ini is used. |
To confirm which ini a site actually loaded, drop this into a PHP file in the account and open it in a browser:
<?php
echo 'ini: ', php_ini_loaded_file(), "\n";
echo 'PHPRC: ', getenv('PHPRC'), "\n";
Set the execution time (and other limits)
The maximum script run time is the standard PHP directive max_execution_time (seconds). Change it globally for a PHP version by editing that version’s php.ini through PHP → Edit php.ini in the admin panel, or per account by creating /home/<user>/php.ini:
; /home/<user>/php.ini -- per-account overrides for cwpsapi
max_execution_time = 300
max_input_time = 300
memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 128M
After editing a per-account php.ini the change is picked up on the next request — no panel action is required. The account owner can also edit these values from the user panel → PHP Selector / Edit php.ini.
Important: Under cwpsapi, per-directory .user.ini files are not honored yet (a known limitation). Put per-account overrides in /home/<user>/php.ini instead. php_value/php_flag lines in .htaccess never work on cwpsapi (or suPHP/PHP-FPM) — they are a mod_php-only feature — so use php.ini as well.
LSAPI-Cache (full-page cache)
cwpsapi can serve cached, fully-rendered pages without running PHP at all. Turn it on with the cache option when enabling an account (GUI), or --cache on the CLI. Account owners get a LSAPI-Cache page in the user panel with a one-click Clear cache button; for WordPress, CWP sets up a compatible cache plugin automatically so published changes clear the cache on every edit. See WordPress & LSAPI-Cache.
CWP Secure Kernel note
If the CWP Secure Kernel is enforcing, it must allow lsphp to run and allow the cwpsapi cache path. Current rule sets already permit this; on an older rule set a site can return HTTP 503 “no backend” (lsphp blocked) or serve every request uncached (cache path blocked). The fix is to update the Secure Kernel rules:
/scripts/cwpsecure_update_rules
Common problems
| Symptom | Cause / fix |
|---|---|
Enable is refused | The account’s domains are on PHP-FPM. Switch them to suPHP in WebServers first, or enable with --force. |
| Site returns HTTP 503 “no backend” | Either the pinned PHP version has no lsphp build (run cwp_cwpsapi fix-lsphp), or the Secure Kernel is blocking lsphp (run cwpsecure_update_rules). |
| A php.ini change did not take effect | Confirm the loaded ini with php_ini_loaded_file(). Per-account values must be in /home/<user>/php.ini; .user.ini is not yet honored on cwpsapi. |
| Wrong PHP version after a Selector change | Run /scripts/cwp_cwpsapi sync to re-pin accounts to their chosen version. |