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.
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 from 8th August, 2026. Support for existing servers will be enabled in a later phase after the required network-level changes are completed. Also, the existing fleet will be covered in the next 2 weeks tentatively.
Running Composer, Artisan, or other CLI tools?
If a command fails or uses the wrong PHP version over SSH, see Running Composer and Other CLI Commands Over SSH.
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.
Running Composer and Other CLI Commands Over SSH
When an application uses a different PHP version than the server default, CLI tools such as Composer or Artisan can run on the wrong PHP version. This can cause errors like Composer reporting that dependencies don’t match the PHP version.
Why this happens
Commands run as the master user use the server’s default PHP version. Each application can have its own PHP version, so a bare php or composer command in a master session may not match your application. The /usr/bin/php binary is the server default.
Step 1: Find your application’s PHP version
ls -al /home/master/applications/<app_user>/.cw/bin/
The php symlink shows the version, for example php -> /usr/bin/php8.4. To see which version your current session uses, run php -v.
Step 2: Run the command with the correct PHP version
Choose one of these options:
Option A: Connect as the application user. Use the application’s SSH credentials instead of the master credentials. [VERIFY: confirm that bare
phpandcomposerresolve to the application’s PHP version in an application-user SSH session.] See [Difference between Master and Application Credentials] [LINK] and [How to Enable SSH Access for Application Users] [LINK].Option B: Use the full PHP binary path. Replace
8.4with your application’s version:/usr/bin/php8.4 /usr/local/bin/composer install /usr/bin/php8.4 artisan migrate
Step 3: Confirm it worked
Run the command again. Composer should install dependencies without a PHP version mismatch error.
Tips:
Prefer the application user where possible. Commands run as master can create files with the wrong ownership. [VERIFY for Composer’s
vendordirectory.]For WP-CLI, use
/home/master/applications/<app_user>/.cw/bin/wp --path=/home/master/applications/<app_user>/public_html. This wrapper always follows the application’s PHP version.New to Composer? See How to Install and Use Composer.
Quick reference
Situation | What to use |
Running Composer or CLI tools for one application | Application user, or |
Checking an application’s PHP version |
|
Scheduled jobs | Application crontab (see cron section) |
Master user with a bare | Uses the server default version |
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.
Test a New PHP Version on Staging Without Affecting Your Live Site
You can run a newer PHP version on a staging application while your live application stays on its current version, all on the same server.
Create a staging copy of your live application on the same server. Click here to read the article.
Open the staging application → Application Settings → PHP Settings and change its PHP version (for example, 8.3) using the steps above.
Test the site thoroughly.
When ready, change the PHP version of the live application.
Changing PHP on the staging application does not change the live application. Creating a staging application on the same server does not add a separate charge.
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.
How to Verify the PHP Version
After the update, confirm that your application is running on the version you selected. Use any of these methods:
From the Cloudways Platform: Go to Application → Application Settings → PHP Settings. The version shown under PHP Version is the version assigned to the application.
From WordPress: Go to Tools → Site Health → Info → Server. The PHP version field shows the version that WordPress is running on.
From SSH (Advanced): Log in over SSH and run:
cat /home/<fqdn>/<app_user>/.php_version
or list the application’s PHP link:
ls -al /home/master/applications/<app_user>/.cw/bin/
The php -> entry shows the version the application uses (for example, /usr/bin/php8.4).
Note:
The server’s default CLI PHP version can differ from your application’s version. Don’t rely on a bare php -v for this check unless you know your session uses the application’s PHP.
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.
How to Roll Back to the Previous PHP Version
If your application shows errors after the change:
Go to Application → Application Settings → PHP Settings.
Click the edit icon next to PHP Version.
Select the previous PHP version and click Proceed.
Wait for the success notification, then reload your site.
Rolling back restarts the application’s PHP service, so you may see a few seconds of backend downtime again.
If the application still shows errors after the rollback, restore the on-demand backup you took before the change (see How to Restore an Application Backup). Then check the application error logs to identify the incompatible plugin, theme, or code before trying again.
If the issue continues, contact Cloudways Support with the application name, the selected and previous PHP versions, and any error message.
If the issue continues, contact Cloudways Support with the application name, selected PHP version, previous PHP version, and any error message you see.
Composer fails with a PHP version mismatch over SSH?
You are probably connected as the master user, which uses the server default PHP version. Connect as the application user or run Composer with the full PHP path. See Running Composer and Other CLI Commands Over SSH.
php -v shows 8.2 but my application is on 8.4?
This is expected for the master user. The command shows the server default, not the application’s version. Use the steps in the same section to check the application’s version.
I can’t see the PHP Version option for my application?
Application-level PHP selection requires a server running Debian 11 or higher. (Add: where users can check their server’s OS, if it’s shown in the platform.) Servers on Debian 10 or lower don’t support it.
Changing PHP on one application seems to have affected another?
Each application has its own PHP version setting. Check that you edited the intended application. Note that applications without their own selection follow the server default. If the issue persists, contact Support with both application names and the PHP versions before and after.
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?
It depends on how WP-CLI is run. In platform-managed cron jobs and through the application’s .cw/bin/wp wrapper, WP-CLI uses the application’s PHP version. In a master user session, or with a bare wp in a manual cron job, it can use the server default PHP version instead.
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 10th September 2026. The earlier product brief also mentioned a phased rollout, starting with selected users before broader availability.
Do I need separate servers to run different PHP versions?
No. You can run different PHP versions on the same Cloudways server by assigning a PHP version to each application. For example, one application can run PHP 8.1 while another runs PHP 8.4. This requires a server that supports application-level PHP version selection (Debian 11 or higher).
Will changing the PHP version on my staging application affect my live application?
No. Each application, including a staging application, has its own PHP version setting. You can change the staging application to a newer version, test it, and leave the live application on its current version. Other applications on the server are not affected.
How can I check which PHP version my application is using?
The version appears in Application → Application Settings → PHP Settings. You can also verify it from WordPress Site Health or over SSH. See How to Verify the PHP Version in this article.
Can I go back to the previous PHP version if something breaks?
Yes. Open the application’s PHP Settings, click the edit icon next to PHP Version, select the previous version, and click Proceed. If errors continue, restore the on-demand backup you took before the change. See How to Roll Back to the Previous PHP Version in this article.
Why does Composer use a different PHP version than my application?
Composer uses whichever PHP version your SSH session resolves to. As the master user, that’s the server default. To match your application, connect as the application user or run Composer with the full PHP binary path. See Running Composer and Other CLI Commands Over SSH.
Should I use the master user or the application user to run Composer?
Use the application user where possible, since it is tied to a single application. Use master only for server-wide tasks, and always call the full PHP path when you do.
That’s it! We hope this article was helpful.