PHP hosting shaped around your codebase

Any current PHP 8.x release is fair game, right up to PHP 8.4, and the version belongs to the domain rather than to one account-wide default. Older 7.x builds are still on the menu, which is how a long-running legacy project and something you started last week share an account without falling out. Setting it site by site earns its keep in practice. Newer CMS platforms and framework releases usually want PHP 8.2 or above, while an ageing plugin or a custom script may only ever have been tested against an earlier build. A switch takes effect immediately, and reverses just as quickly, so nobody is forcing you to march every site onto a new version on the same afternoon. Move each one at whatever pace suits it. When a fresh PHP release picks up official support we add it, which gives you a clear route onto a current, maintained version well before the one you are on reaches end of life.

One click does it. Open the PHP selector in your control panel, choose the release you want for that domain, and it applies there and then. No ticket to file. No maintenance window to book. Because the setting hangs off the domain, you can rehearse an upgrade on a staging copy first: point it at the newer release, run the app through everything it does, and only then move production across. If the new release causes friction, an outdated function call or a plugin nobody has updated yet, reverting is every bit as instant, so you are never stuck on a version that is giving you grief. Extensions and core settings for the chosen release live on that same panel screen, which is where you enable exactly the modules your app asks for. Put simply, keeping up with PHP here is a couple of minutes of work, rather than a lost afternoon.

Yes. Composer arrives pre-installed on every plan and runs over SSH, so managing PHP dependencies feels no different from working on your own laptop. Log in and composer install, composer update, composer require and composer dump-autoload all fire straight away, against whichever PHP version you picked for that domain. That counts for a lot in modern PHP work, because Laravel, Symfony and an enormous number of standalone libraries ship through Composer rather than as manual downloads. Your composer.json and composer.lock stay where they belong, in your repository, so the exact package versions you verified on your machine are the ones running in production. Composer is only part of it, mind. You get a proper command line for the rest of the job as well: running your framework's own CLI, firing database migrations, clearing caches, scripting a deployment. Cron support means anything you would otherwise kick off by hand can be put on a schedule instead, and none of that needs setting up by us.

Yes. The usual suspects are all there: GD and Imagick for images, mbstring and intl for multibyte and localized text, cURL for outbound calls, PDO with the MySQL drivers for database work, plus OPcache, zip, bcmath and a good many more. Each one is switched on per PHP version, straight from your control panel. The list on offer follows the version you selected, so you can kit out a single site without disturbing anything else on the account. That same panel is where the core php.ini values get adjusted, the ones that trip up busy applications: memory_limit, max_execution_time and the upload size caps. Match a CMS or framework's stated requirements exactly rather than guessing. Most extensions come alive the moment you tick them, no ticket involved. For something more obscure that your app depends on, support will check whether it is available and talk you through enabling it, so you are never left guessing whether a module exists at all.

Almost certainly. Laravel, Symfony, CodeIgniter and Slim all run cleanly, and so do the big content and store platforms: WordPress, Drupal, Joomla and Magento. None of that is surprising, since they are ordinary PHP software sitting on a fully equipped, ordinary PHP stack. A smooth install mostly comes down to matching the environment to what the software asks for. Pick the PHP version it supports, enable the extensions it lists, and raise memory_limit or the upload cap where its documentation says to. After that, deploy in whatever way suits you: a one-click installer for the well-known platforms, or Git and Composer for a framework build or your own code. A real CLI plus cron cover the scheduled work these systems lean on, from queue workers through to the nightly cleanup task nobody thinks about. Unsure whether some particular app will fit? Support has probably seen it already and can steer you the right way.

Speed here is a stack of layers rather than a single switch. NVMe SSD storage cuts the disk latency sitting behind every file read and database query, so a page assembles quickly. OPcache keeps your compiled PHP bytecode in memory, which spares the server from recompiling scripts on each request, and that is a real win on framework-heavy applications. Server-level caching shortens the journey to a rendered page for anyone coming back a second time, while object caching takes weight off the database for values your app keeps asking for. Beneath all of it sits CloudLinux, handing every account a resource lane of its own. A runaway script on the site next door cannot quietly starve yours of CPU or memory during a traffic surge, which is why your app behaves the same at its busiest as it does when nobody is about. Tune OPcache, the realpath cache and your PHP version to the workload and you claw back whatever response time is still on the table.