Running multiple PHP versions on the same server has always been one of the messier aspects of hosting administration. A customer needs PHP 8.0 for a legacy application. Another needs 8.3 for the latest Laravel. A third is running WordPress and wants whatever version is recommended this month. On a traditional LAMP server, satisfying all three simultaneously requires careful configuration — and still creates shared dependencies that can bite you during upgrades.
On a container-based hosting platform, this problem doesn't exist. Each domain specifies its PHP version as a container image. They run side by side without interaction.
How PHP Versions Work on Traditional Servers
On a cPanel or DirectAdmin server, PHP is installed as a system package. There's one primary PHP version that serves as the default for all accounts. Running a different version requires additional configuration:
- MultiPHP on cPanel: cPanel supports multiple PHP versions via EasyApache 4, which installs each version as a separate package. Accounts can select their version through the MultiPHP Manager. This works, but it means all PHP versions are installed at the OS level — shared across all accounts.
- CloudLinux: Adds per-account PHP version selection with better isolation through CageFS. This is the production-grade solution on cPanel, but it costs an additional $12–15/month per server.
- PHP-FPM pools: DirectAdmin and others use separate PHP-FPM pools per version, which is cleaner but still means each version is a system package with shared configuration.
The shared nature of these approaches creates real operational risk. An OS update that affects a system PHP package affects every account using that version. A misconfiguration in a shared php.ini affects all accounts on that version. Upgrading the system's PHP requires testing all affected accounts simultaneously.
How Container Isolation Solves This
With container-per-domain hosting, each domain runs its own container image. The PHP version isn't a system package — it's part of the container image. This means:
True Version Isolation
Domain A runs the kubepanel/php80:v1.0 image. Domain B runs kubepanel/php83:v1.0. These are entirely separate filesystems, separate processes, separate PHP configurations. There is no shared state between them at the OS level.
Updating Domain B's PHP from 8.3 to a patched 8.3 image means swapping its container image. Domain A is unaffected — it continues running its 8.0 image until you explicitly choose to update it.
Per-Domain php.ini
Because each domain has its own container, php.ini configuration is per-domain by default. One customer can have memory_limit = 256M. Another can have memory_limit = 512M. A third running a memory-intensive application can have memory_limit = 1G. These are container-level settings that don't affect each other.
Admin-Configurable Versions
In KubePanel, PHP versions are defined as WorkloadVersion records in the admin panel. Adding a new PHP version means registering a container image URL — no OS package installation, no server-level changes. The new version becomes available to all accounts immediately.
KubePanel currently ships with PHP 8.0, 8.1, 8.2, and 8.3 as built-in workload types. Adding a custom PHP version — including versions with specific extensions pre-installed — means building a Docker image and registering it. No server reconfiguration needed.
Beyond PHP: Any Runtime Without Conflicts
The container model extends beyond PHP. Because runtimes are container images rather than OS packages, there's no concept of "runtime conflict." Consider a server running:
- Domain A: PHP 8.3 (Laravel application)
- Domain B: PHP 8.0 (legacy application)
- Domain C: Python 3.12 (Django application)
- Domain D: Node.js 22 (Next.js application)
- Domain E: WordPress with PHP 8.2 (one-click preinstall)
On a traditional LAMP server, this combination requires significant custom configuration and creates maintenance complexity. On a KubePanel cluster, it's the default behavior — each domain picks its workload type and version, and they run independently.
Practical Upgrade Scenarios
Upgrading One Domain's PHP
On traditional hosting: edit MultiPHP settings for the account, test the site, hope nothing breaks for other accounts sharing PHP-FPM pools.
On KubePanel: change the WorkloadVersion for the domain in the admin panel. The operator updates the container image in the Deployment. The old container gracefully terminates, the new one starts. Other domains are unaffected.
Security Patch Released for PHP 8.2
On traditional hosting: update the system PHP 8.2 package, restart PHP-FPM, hope all accounts using 8.2 are compatible with the patched version.
On KubePanel: publish a new kubepanel/php82:v1.1 image with the patch applied. Update the WorkloadVersion record to point to the new image. Accounts using PHP 8.2 can be updated individually or in batch. Accounts on other versions are not touched.
Customer Requests PHP 7.4 (Legacy)
On traditional hosting: PHP 7.4 is end-of-life and may not be available as a system package on modern OS versions. Significant custom work required.
On KubePanel: build or pull a PHP 7.4 Docker image, register it as a WorkloadVersion. Done. The legacy runtime runs in an isolated container without affecting anything else on the cluster.
Explore KubePanel's multi-workload support to see the full list of supported runtimes and how admin-configurable workload types work.