How to Set PHP Version in HestiaCP by Domain

A WordPress update can require PHP 8.2 while an older Laravel app breaks on it. That is why you should set PHP version HestiaCP at the domain level, not blindly change whatever PHP is installed on the server. One account can run different sites on different PHP-FPM versions when the server has them available.

This is a practical job, not a hosting ritual. Pick the version your application supports, apply it to the right domain, verify the web-facing version, and remove the test file. Do not confuse the command-line PHP version with the PHP version serving your website.

What changing PHP version actually changes

HestiaCP commonly runs PHP through PHP-FPM. PHP-FPM keeps worker processes ready to handle requests from Nginx and Apache. When you choose a PHP version for a web domain, Hestia assigns that domain to a PHP-FPM backend template tied to a specific installed PHP version.

This matters because the php -v result over SSH may not match the version shown by your website. The command-line binary is used for shell commands, cron jobs, Composer, and scripts launched from SSH. Your browser request goes to PHP-FPM. They can be different, and often should be.

For a small shared hosting account, per-domain selection is the useful setting. It lets a newer application move forward without forcing an old plugin, CMS theme, or custom script to move with it.

Before you set PHP version in HestiaCP

Check what the application actually supports. Do not select the newest version just because it is newer. PHP releases remove deprecated behavior, and old code can fail fast after an upgrade. A site might load a blank page, throw a 500 error, or fail only in the admin area after a plugin touches outdated code.

For WordPress, check the WordPress version, active theme, critical plugins, and any custom snippets. For Laravel or another framework, check the framework’s PHP support policy plus package requirements in composer.json. For older PHP applications with no active maintenance, moving to a supported PHP version may require code work rather than a control-panel change.

Back up the site files and database first. If the site is a side project, that can be a quick archive and database export. If it makes money, test the change on a staging copy first. The real trade-off is simple: newer PHP generally brings security, performance, and compatibility with current software, but it can expose old code that has been quietly broken for years.

Also make sure the desired PHP-FPM version is installed and available in your HestiaCP setup. A panel cannot assign a version that does not exist on the server.

Change the PHP version in the HestiaCP panel

Sign in to HestiaCP and open Web. Find the domain you want to change, then select Edit. Do not edit the account unless you intend to review every domain under it.

Open the advanced options for the web domain. The exact screen can vary by Hestia version and server configuration, but look for the Backend Template or PHP-FPM template field. This is the setting that controls the PHP-FPM pool used by the domain.

Choose the template associated with the PHP version you need. Template names commonly include a version identifier, such as PHP-FPM-8_2 or a similar local naming convention. Use the names your panel shows. Do not assume a template name from another server will exist on yours.

Save the domain settings. Hestia should regenerate the relevant web configuration and reload the service configuration as needed. The change usually takes effect quickly, but cached pages may hide the result. Purge any application cache, plugin cache, reverse-proxy cache, or CDN cache before deciding the switch failed.

If your domain has aliases, they normally follow the primary web domain configuration. Separate web domains are separate settings. Changing example.com does not automatically change app.example.com if it was created as its own domain entry.

Do not change the proxy template by mistake

A proxy template controls how Nginx handles requests before they reach the backend. It is not normally where you choose PHP. Changing it without knowing why can alter redirects, caching behavior, or application routing.

For this task, the backend PHP-FPM template is the setting that matters. Keep unrelated web settings alone.

Set a PHP version from the command line

If you manage your own Hestia server, the command line is faster when you have several domains or prefer repeatable changes. First inspect the templates available on the server:

bash v-list-web-templates

Then apply the chosen backend template to one domain. Replace the placeholders with the Hestia user, domain, and the exact template name listed on that server:

bash v-change-web-domain-backend-tpl USER DOMAIN PHP-FPM-8_2

For example, changing one domain under the user alex might look like this:

bash v-change-web-domain-backend-tpl alex example.com PHP-FPM-8_2

Use the template name exactly as returned by the server. If the command reports that a template does not exist, stop there and list the templates again. Guessing names is wasted time.

The command-line route is useful for server owners. On shared hosting, you may only have panel-level access, which is normal. Ular.Host uses HestiaCP and multiple PHP-FPM versions, but the available choices still depend on the server configuration and account access.

Verify the version your website is actually using

The cleanest check is a temporary PHP info file in the document root of the domain. Create a file named something hard to guess, such as check-php-4f83.php, containing:

php <?php phpinfo();

Visit that file in a browser over HTTPS. At the top of the page, confirm the PHP Version value. You can also check the Server API field. For a normal Hestia PHP-FPM setup, it should indicate an FPM/FastCGI handler rather than the CLI.

Delete the file immediately after checking. A public phpinfo() page exposes server and extension details that do not need to be public.

Application-level checks help too. WordPress lists PHP information in Site Health. Laravel can report the running version through a temporary route or environment diagnostics if your application has them. The browser-facing result is the one that counts for normal site traffic.

If SSH is available, use these two checks for different purposes:

bash php -v

This shows the default shell PHP. It does not prove the website changed. To inspect a specific installed binary, use its versioned path if your server provides one, such as:

bash php8.2 -v

Again, that confirms the binary exists. The temporary browser check confirms the domain is assigned to it.

If the site breaks after the switch

A 500 error after changing PHP is usually an application compatibility problem, a missing extension, or a bad cached configuration. Start with the web domain error log in HestiaCP. PHP fatal errors usually name the file, plugin, function, or dependency causing the failure.

Common failures include deprecated functions removed in newer PHP versions, an extension required by the application but missing from that PHP build, old encoded files, and Composer dependencies that were installed for an older runtime. WordPress sites also commonly fail because of an abandoned plugin or a theme with old custom code.

The fastest recovery is to switch the domain back to its previous PHP-FPM template, verify the site returns, then fix the code or dependencies before trying again. That is not a defeat. It is a controlled rollback.

Do not try to solve a PHP compatibility error by changing random Nginx settings, permissions, or database credentials. Read the error first. A clear fatal error is better than an hour of blind panel changes.

Use the least old version that works

There is no prize for keeping a site on an obsolete PHP release, and there is no prize for forcing a new release onto code that cannot run it. Choose a currently supported version that your application, plugins, and dependencies can handle. Keep different domains separate when their requirements differ.

Once the site is working, leave a short note in your project documentation with the selected PHP version and why it was chosen. Six months later, that small note is more useful than guessing which control-panel setting kept an old project alive.