Cloudways now allows you to select a different PHP version for each application on the same server.
This means you can run one application on one PHP version and another application on a different PHP version without changing the PHP version for the entire server.
Previously, PHP version control was mainly handled at the server level. If you changed the PHP version on a server, it could affect all applications hosted on that server.
With application-level PHP version selection, you get more control because each application can use the PHP version that works best for it. This is useful when you host multiple websites, stores, or custom PHP applications on one Cloudways server.
For example, one WordPress site may require PHP 8.2 because of a plugin, while another application on the same server may still need PHP 8.1 because it has not yet been updated.
With this feature, both applications can continue running on the same server using their required PHP versions.
Note:
This Feature is currently in Public Preview.
What Is Application-Level PHP Version Selection?
Application-level PHP version selection allows you to choose the PHP version for a single application instead of applying one PHP version to all applications on the server.
PHP is the programming language used by many applications, including WordPress, Laravel, Magento, and custom PHP websites. Different applications, plugins, themes, or codebases may require different PHP versions to work correctly.
If an application is not compatible with a newer PHP version, changing the PHP version too quickly can cause errors.
This feature helps you manage these differences more safely because the PHP version change applies only to the selected application.
Other applications on the same server continue using their own assigned PHP version or the default server PHP version.
Why Use Application-Level PHP Version Selection?
Use this feature when different applications on the same server need different PHP versions.
It is useful if you manage multiple websites for different clients, run different types of applications, or want to test a newer PHP version before applying it to a live website.
It also helps you avoid creating a separate server only because one application needs a different PHP version.
For example, an agency may host several client websites on one server. Some client websites may be ready for the latest PHP version, while others may still depend on older plugins or custom code.
With this feature, the agency can update each application at its own pace without affecting the others.
How This Feature Helps?
Application-level PHP version selection gives you more flexibility when managing applications on Cloudways.
You can update one application to a newer PHP version while keeping other applications unchanged.
You can also test PHP compatibility on a staging application before making changes to the live application. This helps reduce the risk of site errors and makes PHP upgrades easier to plan.
This feature also reduces the need to contact support for PHP version differences between applications.
You can make the change directly from the Cloudways Platform once the feature is available for your account.
Before You Change the PHP Version
Before changing the PHP version of an application, make sure your website, plugins, themes, framework, and custom code support the PHP version you want to use.
A PHP version change may cause issues if your application is not compatible with the selected version. For example, an older plugin or custom script may not work correctly on a newer PHP version.
To reduce risk, Cloudways recommends testing the PHP version change on a staging application first. A staging application is a copy of your website that you can use for testing without affecting the live site.
You should also take a backup before making the change, especially for production websites or business-critical applications.
PHP version for cron jobs
Cron jobs created from Application → Cron Job Management automatically run with the PHP version assigned to the application. When the job is saved, the platform writes a managed environment header at the top of the application's crontab:
PATH=/var/cw/php_versions/8.2/bin:/usr/local/bin:/usr/bin:/bin
WP_CLI_PHP=/usr/bin/php8.2
/var/cw/php_versions/8.2/bin contains php and wp shims pointing at that version, so a plain php or wp command in the job resolves to the application's PHP — the same interpreter the web requests use. This header is refreshed automatically whenever you change the application's PHP version.
Manually Added Cron jobs:
Cron jobs created manually over SSH (crontab -e) do not get this header unless the crontab was saved through the platform at least once. For those, call the PHP binary by its full path:
Running a PHP script via cron:
* * * * * /usr/bin/phpX.Y /home/master/applications/<app_user>/public_html/script.php
Replace X.Y with the version assigned to your application and update the path accordingly. When you switch the application's PHP version, any /usr/bin/phpX.Y path in the crontab is rewritten to the new version for you, so this style stays correct after a switch.
If you are aiming to add wp cli commands to crontab manually it is recommended to WP_CLI_PHP=/usr/bin/phpX.Y
Do not use a bare `php` in a manually created job unless the managed PATH header is present. Cron runs with a minimal PATH (/usr/bin:/bin), so a bare php resolves to /usr/bin/php, which is the server default PHP version, not the application's.
Setting PATH for PHP in a crontab
You can define your own PATH inside a crontab, but two rules matter:
Assignments are not shell-expanded. Cron reads NAME=value lines literally — no variable substitution, no ~ expansion.
This line does not do what it looks like:
PATH=$HOME/.cw/bin:$PATH # wrong — PATH becomes the literal string
Always write absolute paths:
PATH=/var/cw/php_versions/8.2/bin:/usr/local/bin:/usr/bin:/bin
Variables are expanded in the command portion of a job line, because cron runs commands through /bin/sh. So $HOME works in the command but not in the assignment.
Order decides which binary wins. PATH is searched left to right and the first match wins:
Prepending the version directory (/var/cw/php_versions/8.2/bin:$rest) makes the application's PHP win over the server default.
This is what the platform does.
Appending it (/usr/bin:...:/var/cw/php_versions/8.2/bin) has no effect, because /usr/bin/php is found first. This is the most common reason a job silently runs on the wrong version.
Place assignment lines above the schedule lines they should apply to.
WP-CLI cron jobs
Never write a bare wp. Cron's default PATH for user crontabs is /usr/bin:/bin, which doesn't include /usr/local/bin, so wp usually isn't found at all — and where it is found, the phar's #!/usr/bin/env php shebang boots it on the server default PHP, not the application's.
Use one of these two forms instead:
* * * * * /home/master/applications/xsxcsacac/.cw/bin/wp --path=/home/master/applications/xsxcsacac/public_html cron event run --due-now
or, if you prefer naming the version explicitly:
* * * * * /usr/bin/php8.2 /usr/local/bin/wp --path=/home/master/applications/xsxcsacac/public_html cron event run --due-now
The first is the better default: .cw/bin/wp contains no version number, so it can never go stale. It's a wrapper whose php symlink is retargeted during a PHP switch, meaning the cron line keeps working untouched.
The second is switch-safe too, but by a different mechanism —- the PHP switch rewrites every /usr/bin/phpX.Y occurrence in the crontab to the new version.
If you have many WP-CLI lines, set the environment once at the top instead of repeating the path:
PATH=/var/cw/php_versions/8.2/bin:/usr/local/bin:/usr/bin:/bin
WP_CLI_PHP=/usr/bin/php8.2
* * * * * cd /home/master/applications/xsxcsacac/public_html && wp cron event run --due-now
Both of those lines are rewritten on a PHP switch as well. Note that the assignment must use literal absolute paths — cron does not expand variables in NAME=value lines, so PATH=$HOME/.cw/bin:$PATH silently produces garbage.
Master-user crontabs
On multi-PHP hosts, prefer application crons (Cloudways UI / app user crontab).
A master-user crontab has no pinned PHP version. Bare php / wp will follow the server CLI default, not the app’s PHP — so jobs can run the wrong interpreter or fail after a PHP switch.
Use master cron only for rare server-wide jobs that are not app PHP (shell, backups, non-PHP scripts).
Before you add a master cron
Find the app’s PHP version (not the CLI default):
[master_xxxxxxx]:~$ ls -al /home/master/applications/<app_user>/.cw/bin/
total 12
drwxr-xr-x 2 root root 4096 Aug 4 08:15 .
drwxr-xr-x 3 root root 4096 Aug 4 08:15 ..
lrwxrwxrwx 1 root root 15 Aug 4 08:15 php -> /usr/bin/php8.4
OR
cat /home/<fqdn>/<sys_user>/.php_version
2. Use the app path under master
/home/master/applications/<sys_user>/public_html/…
3. PHP version switch — changing an app’s PHP does not rewrite master crontab. Revisit any job that hardcodes php8.1 / shim paths.
Master crontab example:
PATH=/var/cw/php_versions/8.2/bin:/usr/local/bin:/usr/bin:/bin
WP_CLI_PHP=/usr/bin/php8.2
*/15 * * * * cd /home/master/applications/SYSUSER/public_html && php artisan schedule:run >> /dev/null 2>&1
*/30 * * * * cd /home/master/applications/SYSUSER/public_html && wp cron event run --due-now >> /dev/null 2>&1
Things to consider with wp cron:
Add the job to the application user's crontab, not master's. This is the one most likely to cause a support ticket. The PHP switch only rewrites crontab -l -u <app_user>, so a WP-CLI line sitting in master's crontab is never updated and keeps calling a version that may later be stopped and masked. It also creates files with the wrong ownership.
Always pass --path or cd first. Cron starts in the home directory, not the web root, so WP-CLI can't find the WordPress install on its own.
Set WP_CLI_PHP when using the explicit-binary form. Some WP-CLI commands shell out to child wp processes; without it those children drop back to the server default PHP. It's what the platform does internally for the same reason:
* * * * * WP_CLI_PHP=/usr/bin/php8.2 /usr/bin/php8.2 /usr/local/bin/wp --path=... cron event run --due-now
The .cw/bin/wp form doesn't set this either, so add it there too if the command spawns children.
How they check their version and verify?
Confirm a cron line resolves the way they expect, run the exact command with --info:
/home/master/applications/xsxcsacac/.cw/bin/wp --path=/home/master/applications/xsxcsacac/public_html --info
Important: How the Platform Manages Crontab PATH Entries?
When adding custom directories to the crontab PATH, make sure the PHP version shim directory remains included.
Cloudways combines your custom entries into a single managed PATH. The PHP version shim directory is placed first, while your custom directories are added after the standard system directories. This allows commands such as php to use the PHP version selected for the application.
If you replace the managed PATH with a custom value that does not include the shim directory, Cloudways treats the entire line as customer-managed. The platform will no longer update it when the PHP version changes, and the php command may use the server’s default PHP version instead of the application-specific version.
Availability
Application-Level PHP Version Selection is planned as a Cloudways feature that gives users per-application PHP control.
According to the product brief, the feature is expected to roll out first to selected users and later become generally available to all users.
The brief also states that this feature is included in existing Cloudways plans and does not require an additional paid add-on.
Note:
Initially, this feature will be available only for newly launched servers. Support for existing servers will be enabled in a later phase after the required network-level changes are completed.
Supported Applications
This feature can be used for PHP-based applications hosted on Cloudways, including WordPress, Laravel, Magento, and custom PHP applications.
The available PHP versions may depend on the versions currently supported by Cloudways. If a PHP version is not shown in the platform, it means that version is not available for selection.
Cloudways may not provide very old or unsupported PHP versions because outdated PHP versions can create security and compatibility risks.
How to Change the PHP Version for an Application?
Go through the following steps in this section to learn how to change the PHP Version for an application.
How to Access Server-Level PHP Settings in Cloudways
Before changing the PHP version for a specific application, it is useful to understand where the server-level PHP settings are located.
Server-level PHP settings are available under Settings & Packages inside your server management area.
Note:
Running multiple PHP versions increases memory usage and may result in high RAM consumption on 1 GB or 2 GB servers. For better performance and stability, we recommend using a server with at least 4 GB of RAM when enabling application-specific PHP versions.
Step #1 - Go to Flexible:
Log into your Cloudways Platform, click Flexible from the left-side menu.
Click on My Servers.
Step #3 - Select Your Server:
On the Servers page, select the server where your application is hosted.
Step #4 - Go to Manage Services:
From the server management menu, click Manage Services.
This section shows the server-level packages available on your server, including Apache, Imunify360, NGINX, Redis, and etc.
Now, locate the PHP card.
Note:
PHP versions are selected and managed individually for each application from the application-level settings.
Step #5 - Click on Restart:
You can click on any PHP version, or all versions to restart your PHP on the app.
Important:
Changing the server-level PHP version does not automatically affect applications that already have their own application-level PHP version selected.
Restarting PHP-FPM may briefly pause the applications using the selected PHP version.
Before modifying PHP, always check application compatibility and take a backup if you are changing PHP for.
How to Change the PHP Version for a Specific Application
You can change the PHP version for a single application from Application Settings. This allows you to update the PHP version for one application without changing the PHP version for other applications on the same server.
Note:
The PHP version change applies only to the selected application. Other applications on the same server will continue using their existing PHP version.
Step #1 - Go to Applications:
From the Flexible section, click the Applications tab.
Step #2 - Select Your Application:
From the applications list, select the application for which you want to change the PHP version.
Step #3 - Open Application Settings:
From the left-side application menu, click Application Settings.
Step #4 - Open PHP Settings:
On the Application Settings page, click the PHP Settings tab.
In this section, you can view the current PHP version selected for the application.
Step #5 - Click the Edit Icon:
Under PHP Version, click the edit icon next to the current PHP version.
Step #6 - Select the Required PHP Version:
A popup will appear with the title Update PHP Version.
From the PHP Version dropdown, select the PHP version you want to use for this application.
Cloudways will also show a warning to confirm that your application is compatible with the selected PHP version. If the selected PHP version is not compatible with your application, plugins, themes, framework, or custom code, your application may face issues.
Step #7 - Proceed with the Change:
After selecting the required PHP version, click Proceed.
Updating the PHP version will restart the application’s PHP service. You may experience a few seconds of backend downtime during the update.
Step #8 - Confirm the Update:
Once the PHP version is updated, Cloudways will show a success notification confirming that the application PHP version has been updated successfully.
How to Use the Advanced PHP Editor
The Advanced PHP Editor allows you to customize selected PHP settings for a specific application.
These settings are useful when your application requires custom PHP values, such as memory limit, execution time, upload size, or other supported PHP directives.
Follow the old steps up to Step #3, and continue from below.
Note:
Changes made in the Advanced PHP Editor apply only to the selected application. They do not affect other applications on the same server.
Step #1 - Click PHP Editor:
Under Advanced PHP Editor, click PHP Editor.
Step #2 - Update PHP Directives:
The Advanced PHP Editor popup will open. You can update the allowed PHP directives from this editor.
To activate a setting, remove the semicolon ; from the beginning of the required line and update the value as needed.
After updating the required PHP directives, click Save Changes.
Important
The application-level PHP version applies only to the selected application.
Advanced PHP Editor changes also apply only to the selected application.
Changing the PHP version may restart the application’s PHP service and may cause a few seconds of backend downtime.
Before changing the PHP version, make sure your application, plugins, themes, framework, and custom code are compatible with the selected version.
Cloudways recommends creating an on-demand application backup before applying the PHP version change.
What Happens After You Change the PHP Version?
When you change the PHP version for an application, Cloudways applies the selected PHP version to that application only.
The application’s PHP process may restart during the change. This can cause a very brief interruption for that specific application. Other applications on the same server are not affected by this change.
After the update is complete, you should test the application carefully. Open the website, check important pages, test forms, review the admin area, and confirm that plugins, themes, and custom functionality are working correctly.
Best Practices
Test the change on a staging application before updating the live application. This is especially important when moving to a newer major PHP version.
Review your application requirements before selecting a PHP version. For WordPress, check plugin and theme compatibility. For Laravel, Magento, or custom PHP applications, check the framework and code requirements.
Use supported PHP versions whenever possible. Newer supported PHP versions usually provide better performance and security, but compatibility should always be checked first.
Make PHP version changes during low-traffic hours for important websites. This reduces the impact if you need to troubleshoot or roll back.
Troubleshooting
If your application shows errors after changing the PHP version, the issue is usually related to compatibility. A plugin, theme, framework package, or custom code may not support the selected PHP version.
In this case, switch back to the previous PHP version if the option is available, then review the error logs and application requirements. You can also test the update on staging and fix compatibility issues before applying the change again on the live application.
If the issue continues, contact Cloudways Support with the application name, selected PHP version, previous PHP version, and any error message you see.
Frequently Asked Questions
What is Application-Level PHP Version Selection?
Application-Level PHP Version Selection allows you to choose a PHP version for a specific application instead of applying one PHP version to the entire server. This means different applications on the same server can run on different PHP versions based on their own requirements.
Why should I use Application-Level PHP Version Selection?
You should use this feature when different applications on the same server need different PHP versions. For example, one application may be ready for PHP 8.4, while another application may still need PHP 8.1 because of plugin, theme, framework, or custom code compatibility. This helps you upgrade applications safely without affecting other applications on the same server.
Does changing the PHP version for one application affect other applications on the same server?
No. When you change the PHP version for one application, only that application is affected. Other applications on the same server continue using their own selected PHP version or the server-level default PHP version.
What happens if I change the server-level PHP version?
Changing the server-level PHP version will apply to new applications that inherit the server default. Existing applications that already have their own PHP version selected at the application level will not be affected by the server-level PHP change.
Which PHP version will a new application use by default?
By default, a new application will inherit the server-level PHP version. You can later override this from the application’s PHP settings if you want that application to use a different PHP version.
Where can I change the PHP version for an application?
You can change the PHP version from the application’s settings in the Cloudways Platform. Once the feature is available, you will be able to select the required PHP version from the PHP Version dropdown inside the application settings area.
What PHP versions are supported?
PHP 7.4 and above are supported on servers running Debian 11 or higher. The available PHP versions will be shown in the Cloudways Platform. If a PHP version is not listed, it means that version is not available for selection on that server.
Is this feature available on all Cloudways servers?
This feature is available for servers running Debian 11 or higher. Servers running Debian 10 or lower do not support Application-Level PHP Version Selection.
Will changing the application PHP version affect cron jobs?
Platform-managed cron jobs automatically use the PHP version selected for the application. However, for manually created cron jobs, you must specify the full path to the required PHP binary in the cron command to ensure the job runs with the correct PHP version.
Will WP-CLI use the selected PHP version?
Yes. WP-CLI automatically aligns with the PHP version selected for the application. This helps keep WordPress command-line tasks consistent with the application’s PHP environment.
Will Cron Optimizer use the selected application PHP version?
Yes. Cron Optimizer will also use the selected application-level PHP version. When the PHP version is changed for an application, Cron Optimizer is updated accordingly.
Will backups, restores, or Git deployments be affected?
No. Backups, restores, and Git deployments will continue to work as before. Changing the application-level PHP version does not change these workflows.
Will Database Manager use the application-level PHP version?
No. Database Manager remains tied to the server-level PHP version. This means changing the PHP version for a specific application does not change the PHP version used by Database Manager.
Will Imunify API use the application-level PHP version?
No. Imunify API remains tied to the server-level PHP version. It does not switch based on the PHP version selected for an individual application.
Will New Relic work with application-level PHP versions?
Yes. New Relic will activate according to the application-level PHP version with the correct keys.
Can I use this feature for WordPress only?
No. This feature is not limited to WordPress. You can use it for supported PHP-based applications on Cloudways, including WordPress, Laravel, Magento, and custom PHP applications.
Should I test my application before changing its PHP version?
Yes. You should test your application before changing the PHP version, especially if it is a live website or an ecommerce store. Some plugins, themes, frameworks, or custom code may not support the PHP version you select. Testing on staging first can help you avoid issues on the live application.
Should I take a backup before changing the PHP version?
Yes. Cloudways recommends taking an on-demand backup before changing the application-level PHP version. This helps you restore the application if there are compatibility issues after the change.
Can changing the PHP version break my website?
Yes, it can happen if your application is not compatible with the selected PHP version. For example, an old plugin, theme, framework package, or custom code may not work correctly on a newer PHP version. This is why testing and taking a backup are recommended before applying the change.
Will changing the PHP version cause downtime?
The PHP process for the selected application may restart when the PHP version is changed. This can cause a very brief interruption for that application. Other applications on the same server remain unaffected. The PRFAQ also notes that a PHP restart tooltip will clarify that all PHP versions on the server will restart.
Will using multiple PHP versions affect server performance?
Running multiple PHP versions on one server may slightly increase resource usage. Cloudways will validate server capacity and display warnings where necessary.
Can I bulk change PHP versions across multiple applications?
No. Bulk PHP version changes are not included in the first release. This may be considered in a future update.
Can I manage PHP extensions separately for each application?
No. Per-application PHP extensions and settings are not included in this release. They may be considered as future enhancements.
Are audit logs available for PHP version changes?
No. Audit logs for PHP version changes are not available at launch. Cloudways may evaluate this for a future release.
How can Cloudways Support check which PHP version my application is using?
The selected PHP version appears in the Cloudways Platform UI. The PRFAQ also mentions that each application will have a .phpversion file in the application’s configuration directory for support visibility.
Does this feature cost extra?
No. Application-Level PHP Version Selection is included in existing Cloudways plans and does not require an additional paid add-on.
What are the main limitations of this feature?
The main limitations are that it is not supported on Debian 10 or lower, bulk PHP version changes are not available in the first release, and per-application PHP extensions/settings are not included at launch.
When is Application-Level PHP Version Selection available?
The feature is rolling out to all servers running Debian 11 or higher starting October 2025. The earlier product brief also mentioned a phased rollout, starting with selected users before broader availability.
That’s it! We hope this article was helpful.