EnterraHost
Your PHP version is a dropdown, not a support ticket. On Developer tools under Advanced, the PHP panel carries a version selector and a Restart button beside it, and the change takes effect once the process restarts.
Five versions are available. 7.4, 8.1, 8.3, 8.4 and 8.5. The list marks 8.5 as LATEST and the 8.3 and 8.4 lines as LTS, which is the labelling worth understanding before you pick.
Which one to choose
The newest is not automatically the right answer, and the LTS label is the reason.
A latest release gets new features and security fixes and is also the version an application is least likely to have been tested against. An LTS line has been out long enough that the ecosystem has caught up. If your site runs WordPress, a plugin you rely on, or a framework with its own requirements, the vendor's stated supported range is the more useful input than the tag beside the number.
The panel says as much itself, in the yellow hint beside the selector. Check with the developers of your application for the most appropriate version. That advice is on the screen for a reason.
If nothing you run has an opinion, 8.4 is a sound default today, and 8.3 is the conservative one.
How to change it
Select the version you want in the dropdown. The panel takes the change and asks you to restart.
Press Restart. The version is read when the PHP process starts, so a selector that has moved without a restart is a site still running the old version, and it will keep running it until the process recycles.
Expect a few seconds where requests fail or hang while the worker pool restarts. That is normal and brief, and it is the reason to do this at a quiet moment rather than during a sale.
Checking the PHP version actually changed
The panel will show the new version, which tells you the setting was saved and nothing about what the site is doing. Confirm it from the site instead.
Create a short file in public_html and load it. Any editor works, the Files tab, FTP, or SSH if that is what you already have open.
<?php echo PHP_VERSION;The page shows the version the process is actually running. Delete the file afterwards. It is harmless while it exists and pointless once you have read it, and a file at a guessable address telling strangers about your server is not something to leave behind.
If the page shows the old version, the restart did not take. If the page shows a blank screen or an error, the new version is running and something in your code does not like it, which is the case the next section is about.
What breaks when you move
A major version up is the risky direction. Functions get removed, deprecations become errors, and a plugin written for an older version stops being compatible without actually crashing, which is worse.
A minor version down is the trap people do not expect. Content created or a database migrated while the site ran on a newer version can rely on behaviour the older one does not have, and moving back does not undo the migration.
If the site breaks on a new version, switch back and restart. That is a complete reversal and it works within a second or two, because nothing was migrated to allow the change in the first place.
What else a PHP version change affects
The version decides which build of each PHP extension gets loaded, so a setting that works on one version can behave differently on another. If you have turned on Brotli compression or set a directive in the php.ini editor, changing the PHP version restarts the same process and reloads all of it, and it is worth confirming the site is still compressed afterwards with the Server Check tool.
Opcache settings travel with the version too. A cache configured for one release does not carry its compiled code across a restart into another, so the first requests after a version change are slower while it fills again.