Tutorial

How to Change the Default PHP Version in Terminal (SSH) — Plesk vs cPanel vs Panelica

April 01, 2026

Tutorial April 01, 2026

The Terminal PHP Version Problem Every Server Admin Knows

You SSH into your server. You type php -v. PHP 7.4.33 stares back at you. But your websites are running PHP 8.3. Your Composer install fails with "Your Composer dependencies require a PHP version >= 8.2". Your cron jobs are silently failing because they run under the wrong runtime.

This is one of the most common — and most frustrating — problems in server administration. And it happens on every traditional panel: Plesk, cPanel, HestiaCP, ISPConfig. The web PHP version and the terminal PHP version are managed separately, and changing one doesn't touch the other.

In this guide, we'll show you exactly how to fix this on each panel — and explain why one panel makes it a single click from the UI instead of a multi-step SSH adventure.

What this guide covers:
How to change the default CLI PHP version in Plesk, cPanel/WHM, HestiaCP, ISPConfig — and how Panelica handles it from the panel UI with zero SSH required.

Target searches this article answers:

how to change php version in ssh
change default php cli version ubuntu
plesk change php command line version
cpanel change terminal php version
php -v shows wrong version
composer requires php 8.2 but terminal has 7.4

Why Terminal PHP and Web PHP Are Different

Before we fix anything, it helps to understand why this problem exists at all.

When a visitor loads your website, Nginx or Apache hands the PHP file to PHP-FPM — a long-running process manager that handles requests in parallel. When you run php script.php in your terminal, you're using the PHP CLI binary — a completely separate executable.

These two can be different versions. They often are. The PHP-FPM version is set per-site. The CLI version is a system-wide symlink pointing to whichever PHP binary happens to be at /usr/bin/php or /usr/local/bin/php.

CLI PHP matters in these scenarios:

Composer install / update — Composer runs under the CLI PHP. If it's PHP 7.4, packages requiring 8.x will refuse to install.
Laravel Artisan commands — php artisan migrate, php artisan queue:work — all CLI PHP.
WordPress WP-CLI — WP-CLI wraps the CLI PHP binary.
Cron jobs — Any php /home/user/site/cron.php line in your crontab uses CLI PHP.
SSH-executed scripts — Any PHP script run manually from terminal.
Node.js / Python spawning PHP — If your app forks php as a subprocess, it inherits the system CLI version.

Real impact: A server where websites run PHP 8.3 but the CLI is PHP 7.4 will fail Composer, fail Artisan migrations, and silently corrupt cron jobs — all while the panel shows "PHP 8.3 enabled."

Plesk — How to Change Terminal PHP Version

Plesk Obsidian / Plesk Onyx

Plesk stores its PHP binaries under /opt/plesk/php/{version}/bin/php. The system CLI PHP is managed via Linux's update-alternatives system. There is no Plesk UI option for this — it requires SSH access.

# Step 1: Check your current CLI version
php -v
# PHP 7.4.33 (cli) — the wrong one

# Step 2: List available Plesk PHP versions
ls /opt/plesk/php/
# 7.4  8.0  8.1  8.2  8.3

# Step 3: Set via update-alternatives (if already registered)
sudo update-alternatives --set php /opt/plesk/php/8.3/bin/php

# Step 4: If not registered yet, add them first
sudo update-alternatives --install /usr/bin/php php /opt/plesk/php/8.3/bin/php 83
sudo update-alternatives --install /usr/bin/php php /opt/plesk/php/8.2/bin/php 82
sudo update-alternatives --install /usr/bin/php php /opt/plesk/php/8.1/bin/php 81

# Step 5: Interactive selection (shows numbered list)
sudo update-alternatives --config php

# Step 6: Verify
php -v
# PHP 8.3.x (cli) ✓

# Step 7: Update Composer path too
# Composer caches its PHP path — may need:
composer self-update
# or run with explicit path:
/opt/plesk/php/8.3/bin/php /usr/local/bin/composer install

Common Problems with Plesk CLI PHP

There is no UI button — SSH access is mandatory, every time.
Most users don't know what update-alternatives is.
After Plesk updates or PHP version installs, you may need to redo this.
The Plesk Obsidian panel has no "System CLI PHP" setting anywhere.
This is a system-wide change — you can't set different CLI PHP per user.
Extension paths differ between Plesk PHP versions — wrong symlink = "Unable to load dynamic library" errors.

cPanel/WHM — How to Change Terminal PHP Version

cPanel / WHM / EasyApache 4

cPanel stores PHP binaries at /opt/cpanel/ea-php{version}/root/usr/bin/php. There are three approaches — none of them are a single clean UI step.

Method 1: WHM MultiPHP Manager (Web UI)

WHM → MultiPHP Manager → "System PHP-FPM Version" dropdown.
Warning: This only changes web PHP-FPM. The terminal CLI PHP is NOT changed.

Method 2: SSH Symlink (most reliable)

# List available cPanel PHP binaries
ls /opt/cpanel/ea-php*/root/usr/bin/php

# Create a symlink for the system php command
sudo ln -sf /opt/cpanel/ea-php83/root/usr/bin/php /usr/local/bin/php

# Verify
php -v
# PHP 8.3.x (cli) ✓

Method 3: Per-user via .bashrc alias

# Add to each user's .bashrc
echo 'alias php="/opt/cpanel/ea-php83/root/usr/bin/php"' >> ~/.bashrc
source ~/.bashrc

# For system-wide crons, still need the symlink above
# For other users, repeat for each user's .bashrc

Method 4: EasyApache 4 Rebuild

WHM → EasyApache 4 → PHP Versions → set as default → triggers a full Apache/PHP rebuild. This takes minutes and causes brief service disruption.

Common Problems with cPanel CLI PHP

There is no single "System CLI PHP" button in cPanel or WHM.
The alias method is session-dependent — new SSH sessions may not inherit it in all setups.
Per-user CLI PHP requires editing every user's .bashrc manually.
The symlink method can break after cPanel updates that replace or move PHP binaries.
Extension configuration paths differ — wrong binary = ini conflicts.
EasyApache rebuild causes service interruption — not viable for production.

HestiaCP — How to Change Terminal PHP Version

HestiaCP

HestiaCP installs PHP via Ubuntu/Debian packages. The CLI PHP is managed with update-alternatives — same as bare Ubuntu.

# Check current version
php -v

# Interactive selection
sudo update-alternatives --config php
# Type the number of PHP 8.3 and press Enter

# Or set directly
sudo update-alternatives --set php /usr/bin/php8.3

# Verify
php -v
# PHP 8.3.x (cli) ✓

HestiaCP panel UI has no CLI PHP setting. This change is only possible via SSH with root or sudo access.

Limitations

Panel UI has no CLI PHP management — SSH only.
System-wide change only — no per-user CLI PHP.
Must be redone after PHP package updates.

ISPConfig — How to Change Terminal PHP Version

ISPConfig 3.x

ISPConfig installs PHP via system packages or compiled from source. Like HestiaCP, CLI PHP management falls back to the system's update-alternatives.

# List available PHP alternatives
sudo update-alternatives --list php

# Set PHP 8.3 as default
sudo update-alternatives --set php /usr/bin/php8.3

# Or interactive mode
sudo update-alternatives --config php

# Verify
php -v

ISPConfig allows web PHP version selection per-site, but terminal/CLI PHP management is entirely outside the panel — SSH required.

Limitations

No panel UI for CLI PHP.
System-wide only — no per-user configuration.
Compiled PHP installations may need manual alternative registration.

Panelica — One Click from the Panel, No SSH Required

Panelica takes a fundamentally different approach to system PHP management.

Instead of leaving CLI PHP as an undocumented side concern, Panelica builds a dedicated System PHP management interface directly into the panel. No SSH. No commands. No documentation diving.

How to Get There

Sidebar → Web Server → PHP Settings → System PHP tab

Direct URL: /webserver/php#system-php

What You Get

On the System PHP tab, you see a dropdown listing every installed PHP version (8.1, 8.2, 8.3, 8.4, 8.5). Select one. Click Apply. That's it.

Under the hood, Panelica does something smarter than a symlink:

#!/bin/sh
# /usr/local/bin/php — auto-generated by Panelica
PHP_INI_SCAN_DIR=/opt/panelica/services/php/8.3/etc/conf.d \
  exec /opt/panelica/services/php/8.3/bin/php "$@"

This is a wrapper script, not a symlink. The difference matters: a symlink makes PHP look for extensions in whatever directory Ubuntu's system PHP uses, which causes the dreaded "Unable to load dynamic library" error. The wrapper forces PHP to use Panelica's own extension directory — perfectly isolated, always correct.

What Gets Configured Automatically

When you click Apply on System PHP 8.3, Panelica automatically:

Creates /usr/local/bin/php wrapper pointing to PHP 8.3
Creates per-version commands: php81, php82, php83, php84, php85 — all in /usr/local/bin/
Sets phpize and php-config symlinks to the selected version
Updates the composer wrapper to use the new PHP version
Updates SSH allowed-commands so chroot users can also access the correct PHP

Symlink Status Table

The System PHP page also shows a live status table of all registered commands:

Command	Points To	Status
`php`	/opt/panelica/services/php/8.3/bin/php	✅ OK
`php81`	/opt/panelica/services/php/8.1/bin/php	✅ OK
`php82`	/opt/panelica/services/php/8.2/bin/php	✅ OK
`php83`	/opt/panelica/services/php/8.3/bin/php	✅ OK (default)
`php84`	/opt/panelica/services/php/8.4/bin/php	✅ OK
`phpize`	/opt/panelica/services/php/8.3/bin/phpize	✅ OK
`composer`	Wrapper → PHP 8.3 + composer.phar	✅ OK

CLI Alternative (For Those Who Prefer Terminal)

If you're already in the terminal and want to change system PHP from there, Panelica also provides a CLI command:

# Set system PHP to 8.3
panelica php system-set 8.3

# Check current system PHP
panelica php system-status

# Remove system PHP (revert to OS default)
panelica php system-remove

Instant Effect

The moment you click Apply, every SSH session, cron job, and Composer invocation starts using the new PHP version. No service restart. No session refresh. No undo-able symlinks to keep track of.

No SSH. No update-alternatives. No .bashrc hacks. Just click.

Side-by-Side Comparison

Feature	Plesk	cPanel/WHM	HestiaCP	ISPConfig	Panelica
Change CLI PHP from Panel UI	❌ No	❌ No	❌ No	❌ No	✅ Yes
SSH Required	Yes	Yes	Yes	Yes	No
Per-version commands (php81, php82...)	Manual	Manual	❌ No	❌ No	✅ Automatic
Composer auto-updated	❌ No	❌ No	❌ No	❌ No	✅ Yes
Extension conflict prevention	❌ No	❌ No	❌ No	❌ No	✅ Wrapper system
Symlink/wrapper status visibility	❌ No	❌ No	❌ No	❌ No	✅ Dashboard
Survives panel updates	May break	May break	May break	May break	✅ Always
CLI alternative command	N/A	N/A	N/A	N/A	✅ panelica php system-set
Steps required	4–6 SSH commands	3–5 SSH commands	2–3 SSH commands	2–3 SSH commands	1 click

Common Errors and How Panelica Prevents Them

Error: "Unable to load dynamic library 'imagick.so'"

Why it happens: When you change system PHP via a raw symlink, the new PHP binary looks for extensions in the old PHP version's conf.d directory. It finds extension paths for the wrong version — and crashes on load.

On traditional panels: You need to manually edit INI files, update extension paths, and hope nothing else breaks.

On Panelica: The wrapper script sets PHP_INI_SCAN_DIR to Panelica's own isolated extension directory for that specific PHP version. The OS extension directories are never touched. This error cannot happen.

Error: "Your Composer dependencies require a PHP version >= 8.2"

Why it happens: Your websites run PHP 8.3 via PHP-FPM, but the CLI PHP is still 7.4. Composer runs under CLI PHP — and refuses to install packages requiring 8.x.

On traditional panels: Change CLI PHP via SSH, then manually ensure Composer is using the new binary (alias, PATH override, or full path).

On Panelica: Change system PHP from the panel. The Composer wrapper is automatically updated to use the new PHP version. Next time you run composer install, it already uses PHP 8.3.

Error: "php: command not found" in cron jobs

Why it happens: Cron jobs run with a minimal PATH. If php isn't in a standard location like /usr/local/bin or /usr/bin, the cron fails silently.

On traditional panels: Use full PHP paths in cron definitions — but then changing PHP version means updating every cron line.

On Panelica: The wrapper is always placed at /usr/local/bin/php — a standard PATH location. Crons using php script.php always find it. Changing the system PHP version automatically updates the wrapper — no cron edits needed.

Frequently Asked Questions

How do I check my current PHP CLI version?

Run php -v in your terminal. This shows the CLI (command-line) version. It may be different from the PHP-FPM version your websites use. To check the PHP-FPM version for a specific site, check the site's PHP-FPM pool configuration or your server panel's domain settings.

Why is my terminal PHP version different from my website PHP version?

Web servers (Nginx, Apache) use PHP-FPM — a separate long-running process. When you type php in the terminal, you're calling the CLI binary, which is a different executable. Panelica manages both, and lets you set the CLI version from the panel UI.

Can I have multiple PHP versions available in terminal at the same time?

In Panelica, yes — after setting system PHP, you automatically get php (the default), plus php81, php82, php83, php84, and php85 commands. You can call any version explicitly in scripts. On other panels, setting up per-version shortcuts requires manual configuration.

Will changing CLI PHP affect my websites?

No. CLI PHP and PHP-FPM (web PHP) are completely independent processes. Changing the CLI PHP version only affects terminal sessions, cron jobs, Composer, and any PHP scripts run directly from the command line. Your website PHP-FPM settings are unaffected.

Do I need root access to change CLI PHP in Panelica?

The ROOT admin can change system PHP from the Panelica panel UI without any SSH access. In Plesk, cPanel, HestiaCP, and ISPConfig, changing the system CLI PHP requires root or sudo SSH access. Panelica eliminates this requirement by handling it through the panel's authenticated web interface.

What is the difference between a PHP symlink and Panelica's wrapper script?

A symlink simply points /usr/local/bin/php to a PHP binary. When that binary runs, PHP automatically scans the OS extension directories for that version — which may include directories from a different PHP installation, causing extension loading errors. Panelica's wrapper script sets PHP_INI_SCAN_DIR before executing PHP, forcing it to use only Panelica's isolated extension directory for that version. No cross-version extension conflicts are possible.

The Bottom Line

Every traditional panel — Plesk, cPanel, HestiaCP, ISPConfig — makes you SSH into the server and run update-alternatives, edit symlinks, or add aliases to .bashrc to change your terminal PHP version. It's a legitimate sysadmin task — but it's not something that should require 4 commands and SSH access every time.

Panelica puts system PHP management where it belongs: in the panel. One dropdown. One button. Every PHP version available both as the default php command and as version-specific commands (php81 through php85). Composer updated automatically. Extension conflicts impossible by design.

That's the difference between a panel that manages servers and a panel that manages them properly.

See It in Action

Panelica is free to try for 14 days — no credit card required. The entire platform, including System PHP management, is available from day one.

Try Panelica Free 5-Layer PHP Isolation Deep Dive Best Server Panel 2026 Comparison