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

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.

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)

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

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

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"

Then immediately:

$ php -v

PHP 8.5.0 (cli)



$ composer install

Installing dependencies from lock file...

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

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

echo 'export PATH="/opt/alt/php85/usr/bin:$PATH"' >> ~/.zshrc

source ~/.zshrc

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

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

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.