The PHP release you ask for is the one you get

Any current PHP 8.x build, up to and including PHP 8.4 — and the choice is made per domain rather than once for the whole account. Older 7.x builds are still stocked too, so a long-running legacy site and something you started last week can share one account without argument. Setting it site by site matters more than it sounds. Newer CMS platforms and framework releases generally want PHP 8.2 or above, while an ageing plugin or a script somebody wrote years ago may only have been tested against an earlier build. Switching applies straight away and reverses just as quickly, so nothing obliges you to march every site onto a new release on the same afternoon — move each one when it is ready. As new releases reach official support we add them to the shelf, which keeps a clear path onto a maintained version well before the one you are on stops getting fixes.

One click, and that is the whole job. Open the PHP selector in your control panel, choose the release for that domain, and it applies immediately — no ticket to raise, no maintenance window to book. Because the setting is per domain, an upgrade can be rehearsed properly: point a staging copy at the newer release, exercise the app, and only move production once it behaves. If a release does cause friction — a function that was removed, a plugin whose author has not caught up — going back is equally instant, so nothing traps you on a version that is giving you grief. That same screen holds the extensions and core settings for whichever release you picked, so switching on the modules an app needs happens in the same visit. Keeping current with PHP is a two-minute errand here rather than an afternoon's project.

It is, on every plan, installed and reachable over SSH, so dependency work feels exactly as it does on your own machine. Log in and composer install, composer update, composer require and composer dump-autoload run immediately against whichever PHP release that domain is set to. For modern PHP that matters, because Laravel, Symfony and an enormous number of standalone libraries are distributed through Composer rather than as a zip you download and unpack. Your composer.json and composer.lock stay in your repository and stay in charge, so the versions you verified locally are the versions that end up serving traffic. Composer aside, you get a genuine command line for the rest of the routine — running a framework's CLI, firing migrations, clearing caches, scripting a deploy. Cron is there as well, so anything you would otherwise trigger by hand can run to a schedule with nothing to arrange on our side.

Yes, straight from the panel and without asking anyone. The modules most projects reach for are stocked: GD and Imagick for images, mbstring and intl for multibyte and localized text, cURL for outbound requests, PDO with the MySQL drivers for database work, plus OPcache, zip, bcmath and a long tail of others. The list follows the PHP release you chose for that domain, so one site can be equipped exactly as it needs without disturbing anything else on the account. The same screen holds the php.ini values that trip up busy software — memory_limit, max_execution_time, the upload caps — which means meeting a CMS or framework's stated requirements is a matter of matching the numbers in its documentation. Most extensions come alive the moment you enable them. For something more obscure that your app depends on, support will check availability and walk you through turning it on, so you are never left guessing whether a module exists.

Almost certainly. Laravel, Symfony, CodeIgniter and Slim all run cleanly, as do the big content and commerce platforms — WordPress, Drupal, Joomla and Magento — because they are ordinary PHP software sitting on a fully equipped, ordinary PHP stack. A smooth install mostly comes down to matching the environment to the requirements page: choose the PHP release it supports, enable the extensions it lists, and lift memory_limit or the upload cap if the docs ask for more. After that, deploy however you like — the one-click installer for the well-known platforms, or Git and Composer for a framework build or your own code. A real CLI and cron cover the scheduled work these systems depend on, from queue workers to the nightly tidy-up. Unsure whether one particular app fits? Ask us. Chances are we have set it up before and can tell you plainly.

From several layers doing their part, not from one magic setting. NVMe SSD storage takes the disk latency out of every file read and database query, so pages assemble quickly. OPcache keeps compiled PHP bytecode resident in memory, which means the server is not recompiling your scripts on every single request — a noticeable win on framework-heavy applications. Server-level caching shortens the journey to a rendered page for repeat visitors, and object caching spares the database from answering the same question over and over. Beneath all of it, CloudLinux gives every account its own ration of CPU and memory, so a neighbouring site having a bad day cannot quietly eat yours during a traffic surge — busy hour or quiet hour, your app performs the same. Once that is in place, tuning OPcache, the realpath cache and your PHP release for the particular workload collects whatever response time is still on the table.