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. ```plaintext 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. ```bash $ 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: ```bash 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: ```bash 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`: ```bash export PATH="/opt/alt/php85/usr/bin:$PATH" ``` Then immediately: ```bash $ 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: ```bash echo 'export PATH="/opt/alt/php85/usr/bin:$PATH"' >> ~/.bashrc source ~/.bashrc ``` If you're using `zsh` (less common on shared hosts but possible): ```bash 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: ```bash $ 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 | 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.*