DEV Community

Sanon Joas
Sanon Joas

Posted on

How I Fixed a PHP Version Mismatch on Hostinger Shared Hosting (And What Actually Made It Work)

#programming #laravel #php #webdev

I spent way too long staring at this error. If you're here, you probably are too.

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires php ^8.3 but your php version (8.2.30)
      does not satisfy that requirement.
Enter fullscreen mode Exit fullscreen mode

My Laravel 13 app needed PHP 8.3. My Hostinger server was running 8.2. composer install refused to budge. Here's exactly what happened and the one-liner that fixed it.

The Setup

I was deploying a Laravel 13 + Inertia + React app to Hostinger shared hosting. Laravel 13 requires PHP 8.3 minimum — and so do its locked Symfony 8.x and PHPUnit 12.x dependencies. My composer.lock had been generated on a local machine with PHP 8.3, but Hostinger's CLI was defaulting to 8.2.

The hPanel showed PHP 8.3 selected under PHP Configuration. The website itself was running fine on 8.3. But SSH? Still on 8.2.

$ php -v
PHP 8.2.30 (cli)
Enter fullscreen mode Exit fullscreen mode

That disconnect — hPanel vs. CLI — is the trap.

What I Tried First

composer update

My first instinct was to just let Composer resolve newer compatible versions:

composer update
Enter fullscreen mode Exit fullscreen mode

No luck. The root composer.json itself declared "php": "^8.3", so Composer refused before even touching the lock file. The PHP constraint wasn't just in dependencies — it was in my own project requirements.

composer install --ignore-platform-reqs

This flag skips platform checks and forces the install anyway. It works, but it's a lie — you end up with packages that may behave incorrectly or fail at runtime because they genuinely require PHP 8.3 features. Not a real fix.

Changing PHP in hPanel

Hostinger's control panel has a PHP version switcher under Hosting → Manage → PHP Configuration. I had already set this to 8.3. This controls the web server / FPM version — what runs your .php files in the browser. It does not change what php points to in your SSH terminal.

That's the key distinction most tutorials miss.

What Actually Fixed It

Hostinger installs multiple PHP versions in parallel. They live in /opt/alt/phpXX/usr/bin/. I confirmed this:

ls /opt/alt/
# php74  php80  php81  php82  php83  php85
Enter fullscreen mode Exit fullscreen mode

The php command in my shell was just an alias pointing at 8.2. To override it, I prepended the 8.5 binary path to my $PATH:

export PATH="/opt/alt/php85/usr/bin:$PATH"
Enter fullscreen mode Exit fullscreen mode

Then immediately:

$ php -v
PHP 8.5.0 (cli)

$ composer install
Installing dependencies from lock file...
Enter fullscreen mode Exit fullscreen mode

Everything resolved. Clean install.

Making It Permanent

The export command only lasts for your current SSH session. To make it stick, add it to your shell profile:

echo 'export PATH="/opt/alt/php85/usr/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
Enter fullscreen mode Exit fullscreen mode

If you're using zsh (less common on shared hosts but possible):

echo 'export PATH="/opt/alt/php85/usr/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
Enter fullscreen mode Exit fullscreen mode

Now every new SSH session will default to your chosen PHP version.

Why This Works

On shared hosting, the server runs many customers with potentially different PHP version requirements. Hostinger solves this by installing every version in its own isolated directory under /opt/alt/. Your hPanel selection sets an environment variable or symlink that the web server reads when handling HTTP requests — but your SSH shell starts with its own default $PATH that may point somewhere else entirely.

By putting the right /opt/alt/phpXX/usr/bin at the front of $PATH, you tell the shell to find php there before checking anywhere else. which php will confirm the change:

$ which php
/opt/alt/php85/usr/bin/php
Enter fullscreen mode Exit fullscreen mode

Composer reads php from your $PATH too, so once the CLI version is right, composer install and composer update both work correctly without any flags or workarounds.

TL;DR

Action Effect
Change PHP in hPanel Fixes web/browser PHP version only
composer install --ignore-platform-reqs Dangerous workaround, not a real fix
export PATH="/opt/alt/php85/usr/bin:$PATH" Fixes CLI PHP version — this is the fix
Add the export to ~/.bashrc Makes it permanent across SSH sessions

If you're on Hostinger (or any cPanel-based shared host with alt-php), the version mismatch between hPanel and SSH CLI is almost always the culprit. The $PATH override is the clean, correct solution.

Deploying a Laravel app to shared hosting? The combination of PHP version mismatches, composer.lock conflicts, and the hPanel/CLI disconnect can burn hours. Hope this saves you some.

Top comments (0)