Per-Site PHP Selector Now Available in Beta: Phase 2 of Website Isolation

In January, we launched the beta of Per-Site CageFS Isolation as the first phase of our Website Isolation project, introducing file system isolation between websites within the same hosting account.

Today, we’re delivering Phase 2 with two significant additions: Per-Site PHP Selector, which lets each isolated website run its own PHP version and extensions, and a new self-service activation model that gives hosting providers granular control over who can use Website Isolation and lets end users manage isolation for their own domains.

Per-Site PHP Selector

Until now, all websites under a single hosting account shared the same PHP version and extension configuration set through CloudLinux PHP Selector. If one site required PHP 8.2 with imagick and another needed PHP 8.3 with redis, the only option was to choose a single configuration for the entire account, or move one site to a separate account. 

This is a common friction point in various environments:

• Shared hosting: A customer’s primary domain runs a legacy application on PHP 7.4, while an addon domain needs PHP 8.3 for a modern storefront.
• VPS: An agency manages several client sites under one account, each built with different PHP requirements.
• Staging: A developer needs to test a PHP version upgrade on staging without changing the production site’s configuration.

Per-Site PHP Selector removes this constraint. Each isolated website gets its own independent PHP configuration:

• Individual PHP versions per site. Set PHP 7.4 for a legacy application and PHP 8.3 for a modern one.
• Independent extension management. Enable or disable PHP extensions on a per-site basis without affecting other websites.
• Automatic inheritance. When isolation is enabled for a domain, it inherits the user’s current PHP version and extension settings. Further changes to per-user settings are independent from per-site settings.

Per-Site PHP Selector is automatically initialized when isolation is enabled for a domain. No separate activation step is needed. The selectorctl –domain commands become available once a domain is isolated.

Setting PHP Version for an Isolated Domain

Use selectorctl with the new –domain option:

selectorctl --set-user-current 8.2 --domain <DOMAIN>When running as root, add –user <USERNAME> to specify the account:

selectorctl --set-user-current 8.2 --domain <DOMAIN> --user <USERNAME>

Managing Extensions per Domain

selectorctl --enable-user-extensions redis,imagick --domain <DOMAIN>selectorctl --disable-user-extensions imagick --domain <DOMAIN> 

Self-Service Activation and Access Control

Website Isolation now uses a two-step activation model:

1. Server administrator allows the feature for users — this grants the right to use isolation but does not enable it on any domain.
2. User enables isolation for specific domains.

This model introduces two capabilities that were not available in Phase 1: user self-service and per-user access control.

User Self-Service

In Phase 1, only server administrators could enable or disable isolation. End users can now manage their own domains directly:

cagefsctl-user site-isolation-enable --domain <domain>[,<domain2>,...]cagefsctl-user site-isolation-disable --domain <domain>[,<domain2>,...]

This means hosting providers can offer Website Isolation as a self-service feature, reducing support overhead.

Per-User Access Control

Server administrators now control which users can access Website Isolation:

cagefsctl --site-isolation-allow-all
cagefsctl --site-isolation-allow <USERNAME>
cagefsctl --site-isolation-deny <USERNAME>
cagefsctl --site-isolation-deny-allAll allow / deny commands require root. They grant or revoke the right to use isolation, but they do not enable isolation on any domain.

This gives hosting providers the flexibility to include Website Isolation in specific hosting plans or offer it as a premium add-on, controlling exactly which customers have access.

Changes for Phase 1 Beta Users

Atomic Enable/Disable

In Phase 1, –site-isolation-enable only activated CageFS file system isolation for a domain. Starting with this release, it is an atomic action that enables both components at once:

• CageFS per domain (file system isolation)
• PHP Selector per domain (independent PHP version and extensions)

The same applies to –site-isolation-disable. It removes all components in a single step, and the domain returns to shared per-user settings.

Command Renames

Previous Command (Phase 1)	New Command
cagefsctl –site-isolation-allow	cagefsctl –site-isolation-allow-all
cagefsctl –site-isolation-deny	cagefsctl –site-isolation-deny-all

The –site-isolation-allow and –site-isolation-deny commands now operate at the per-user level.

Example: Isolating a Domain with Custom PHP

1. Root allows the feature (one-time):

cagefsctl --site-isolation-allow-all

2. User enables isolation for the domain:

cagefsctl-user site-isolation-enable --domain shop.example.com

The domain is now isolated. CageFS and PHP Selector are active. PHP version and extensions are inherited from the user’s account-level settings.

3. User sets the desired PHP version:

selectorctl --set-user-current 8.2 --domain <shop.example.com>

4. User enables needed extensions:

selectorctl --enable-user-extensions redis,imagick --domain <shop.example.com>Done. The domain now has its own PHP 8.2 with redis and imagick, independent from other domains on the same account.

Get Started Today

Update the required packages from the testing repository:

yum update lvemanager cagefs lve-stats lve-utils --enablerepo=cloudlinux-updates-testing

Minimum Package Versions

For compatible PHP handlers and the full command reference, visit the Website Isolation documentation.

Project Roadmap

1. CageFS per site: file system isolation between websites ✅ Released
2. PHP Selector per site: individual PHP versions and extensions per website ← current release
3. LVE per site: individual resource limits for each website

We invite you to start testing and share your feedback, helping us refine this feature. If you run into any technical issues, please open a ticket with our support team.

Next up: Phase 3 will introduce per-site LVE resource limits, giving each isolated website its own CPU, memory, and I/O allocation.