LiveChat 
Support 
PHP Installation on Ubuntu: Managing Multiple PHP Versions Side by Side
Most PHP tutorials assume you install one version and never look back. Real servers are messier. A legacy storefront still needs PHP 7.4, your main application targets PHP 8.3, and a client project sits somewhere in between on PHP 8.1. The good news: Ubuntu handles all of this gracefully. You can install several PHP versions side by side, run a different version per website, and switch the command-line default whenever you need to — without uninstalling anything.
This guide focuses specifically on multi-version PHP management on Ubuntu. If you just need a single working PHP installation from scratch, start with our canonical walkthrough at , then come back here when you need more than one version.
Key Takeaways
• The ondrej/php PPA lets you install multiple PHP versions (7.4, 8.1, 8.3, and more) that coexist peacefully on one Ubuntu server.
• `update-alternatives –config php` switches the CLI default, while each web server vhost points to its own PHP-FPM socket to set the per-site version.
• The CLI PHP version and the version your websites run are completely independent — a common source of confusion.
• Run only actively supported PHP versions where possible; unsupported releases stop receiving security patches.
• Remove old versions cleanly with `apt purge` once no site or script depends on them.
Why would you run multiple PHP versions on one server?
The single most common reason is application compatibility. PHP’s release cycle moves quickly, and not every codebase keeps up. A few realistic scenarios:
- A legacy application built years ago throws fatal errors on PHP 8.x because of removed functions or changed type behavior, so it must stay on 7.4.
- A modern framework requires PHP 8.2 or newer to use the latest syntax and performance gains.
- You host multiple client sites on one VPS, each pinned to whatever version its developers tested against.
- You want to stage an upgrade — running a copy of a site on a newer PHP version to catch deprecations before switching production.
Rather than maintaining separate servers for each requirement, installing versions side by side keeps everything on one machine while preserving isolation. Each version has its own binaries, its own configuration directory under `/etc/php/`, and its own FPM service.
How do you install multiple PHP versions on Ubuntu?
Ubuntu’s default repositories typically ship only one PHP version per release. To install several, add the widely trusted ondrej/php PPA, which packages every maintained PHP version (and many older ones) for current Ubuntu releases.
Add the PPA
“`bash sudo apt update sudo apt install -y software-properties-common sudo add-apt-repository ppa:ondrej/php sudo apt update “`
Install several versions at once
Each version is namespaced by its number, so the packages never collide:
“`bash
sudo apt install -y php7.4 php7.4-cli php7.4-fpm php7.4-common sudo apt install -y php8.1 php8.1-cli php8.1-fpm php8.1-common sudo apt install -y php8.3 php8.3-cli php8.3-fpm php8.3-common “`
Add the extensions each application needs, again version-prefixed:
“`bash sudo apt install -y php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-zip sudo apt install -y php7.4-mysql php7.4-xml php7.4-mbstring php7.4-curl php7.4-zip “`
After installation, each version exposes its own CLI binary (`php7.4`, `php8.1`, `php8.3`) and its own FPM service (`php7.4-fpm`, `php8.1-fpm`, `php8.3-fpm`). They run completely independently.
How do you check which PHP versions are installed?
To list every PHP runtime currently on the system:
“`bash
ls /usr/bin/php*
dpkg -l | grep -E ‘php[0-9]’ “`
Check a specific version directly by calling its binary:
“`bash php7.4 –version php8.1 –version php8.3 –version “`
To see which FPM services exist and whether they’re running:
“`bash systemctl list-units –type=service | grep php “`
This separation matters: each `phpX.Y-fpm` service can be started, stopped, and enabled on its own, so you only run the FPM pools you actually use.
How do you switch the default CLI PHP version?
When you simply type `php` on the command line, Ubuntu resolves it through the alternatives system. To change which version that points to:
“`bash sudo update-alternatives –config php “`
You’ll see an interactive menu:
“` There are 3 choices for the alternative php (providing /usr/bin/php).
Selection Path Priority Status
———————————————————— * 0 /usr/bin/php8.3 83 auto mode 1 /usr/bin/php7.4 74 manual mode 2 /usr/bin/php8.1 81 manual mode 3 /usr/bin/php8.3 83 manual mode
Press
Pick the number you want, and `php –version` will reflect the new default. You can also set it non-interactively:
“`bash sudo update-alternatives –set php /usr/bin/php8.1 “`
If you also manage Composer or other PHP-driven tools globally, set the matching alternatives for `phar` and `phar.phar` the same way.
The trap that catches almost everyone: the CLI PHP version you set with `update-alternatives` has *nothing to do with* the PHP version your websites actually run. Your terminal might report `php8.3`, while your Nginx site quietly serves requests through `php7.4-fpm` — because the web server talks to a specific FPM socket, not to the `php` command. People run `php -v`, see 8.3, and spend an hour puzzled over why their site still behaves like it’s on 7.4. Always remember: CLI version and web/FPM version are configured in two different places and can legitimately differ. When debugging a live site, trust a `phpinfo()` page served by the web server over whatever `php -v` says in your shell.
How do you set a different PHP version per website?
This is where multi-version hosting earns its keep. Each website’s PHP version is determined by which FPM socket its web server passes requests to — not by the CLI default. For deeper FPM and Nginx tuning beyond version selection, see .
Per-site PHP version with Nginx
Each FPM version listens on its own Unix socket, typically:
“` /run/php/php7.4-fpm.sock /run/php/php8.1-fpm.sock /run/php/php8.3-fpm.sock “`
In a site’s server block, point `fastcgi_pass` at the socket for the version that site needs:
“`nginx
server { server_name legacy.example.com; root /var/www/legacy-app; index index.php;
location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; } } “`
“`nginx
server { server_name app.example.com; root /var/www/modern-app; index index.php;
location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } } “`
Make sure the corresponding FPM service is running, then reload Nginx:
“`bash sudo systemctl enable –now php7.4-fpm php8.3-fpm sudo nginx -t && sudo systemctl reload nginx “`
Per-site PHP version with Apache
With Apache and `mod_proxy_fcgi`, route each virtual host to the FPM socket you want using a `SetHandler`:
“`apache
Enable the required modules once, then reload:
“`bash sudo a2enmod proxy_fcgi setenvif sudo a2enconf php7.4-fpm sudo systemctl reload apache2 “`
The result: two sites on the same server, each running the exact PHP version it was built for, with zero conflict.
Which PHP versions are supported, and how do you stay secure?
Running a version side by side is convenient, but legacy versions stop receiving security updates once they reach end of life. Use unsupported versions only for isolated legacy apps you cannot yet migrate, and keep them off the public internet where possible. The PHP project maintains each release with roughly two years of active support followed by a year of security-only fixes.
| PHP Version | Typical Support Status | Recommended Use |
|---|---|---|
| 7.4 | End of life | Legacy apps only; migrate when feasible |
| 8.0 | End of life | Avoid for new work |
| 8.1 | Security fixes / nearing EOL | Acceptable short-term; plan an upgrade |
| 8.2 | Actively supported | Solid production choice |
| 8.3 | Actively supported | Recommended for new projects |
| 8.4 | Actively supported (latest) | Newest features; verify app compatibility |
Support windows shift over time. Always confirm the current status on the official PHP supported-versions page before pinning a production site to a release.
Keep every installed version patched:
“`bash sudo apt update && sudo apt upgrade “`
This updates *all* installed PHP versions to their latest available patch release, so even a legacy 7.4 install receives whatever fixes the PPA still provides.
How do you remove an old PHP version?
Once no site or cron job depends on a version, remove it cleanly. First confirm nothing references its socket — grep your web server configs:
“`bash grep -r “php7.4-fpm.sock” /etc/nginx/ /etc/apache2/ “`
If that returns nothing, purge the packages:
“`bash sudo systemctl stop php7.4-fpm sudo apt purge -y ‘php7.4*’ sudo apt autoremove -y “`
Using `apt purge` (rather than `remove`) also deletes the configuration under `/etc/php/7.4/`, leaving the system tidy. Reload your web server afterward to drop any lingering references.
Quick command reference
| Task | Command | |
|---|---|---|
| List installed versions | `dpkg -l \ | grep -E ‘php[0-9]’` |
| Check a version | `php8.3 –version` | |
| Switch CLI default | `sudo update-alternatives –config php` | |
| Set CLI default directly | `sudo update-alternatives –set php /usr/bin/php8.1` | |
| Restart an FPM version | `sudo systemctl restart php8.3-fpm` | |
| Enable an FPM version | `sudo systemctl enable –now php8.1-fpm` | |
| Remove a version | `sudo apt purge ‘php7.4*’` |
Let DarazHost handle the heavy lifting
Managing multiple PHP versions from the command line is powerful, but it isn’t always how you want to spend your afternoon. DarazHost makes it simpler at both ends of the spectrum:
- On cPanel hosting, the built-in MultiPHP Manager lets you set the PHP version per domain in a single click — no PPAs, no sockets, no `update-alternatives`. Pin one domain to 7.4 and another to 8.3 from a dropdown.
- On VPS plans with full root access, you get the freedom to run as many `php-fpm` versions side by side as your projects demand, exactly as described in this guide, with the performance headroom to back it.
Either way, our team is available 24/7 to help you install, switch, or troubleshoot PHP versions so your legacy and modern apps both keep running.
Frequently asked questions
Can PHP 7.4 and PHP 8.3 really run at the same time on one Ubuntu server? Yes. With the ondrej/php PPA, each version installs into its own paths and runs its own FPM service. They never overwrite each other, so multiple versions serve different sites simultaneously without conflict.
Why does my site behave like an old PHP version even though `php -v` shows the new one? Because `php -v` reports the CLI version, while your website runs through PHP-FPM. The web server connects to a specific FPM socket set in your Nginx or Apache config. Check the `fastcgi_pass` (Nginx) or `SetHandler` (Apache) line, and confirm with a `phpinfo()` page served by the site itself.
Does changing the CLI default with `update-alternatives` affect my websites? No. `update-alternatives –config php` only changes which version runs when you type `php` in the terminal. Your websites keep using whatever FPM socket their vhost points to until you change that vhost directly.
How do I know which PHP version my application needs? Check the project’s documentation or its `composer.json` `require` block, which usually specifies a PHP constraint such as `”php”: “>=8.1″`. When in doubt, test the app on a candidate version in a staging vhost before switching production.
Is it safe to keep an end-of-life PHP version installed? Only for isolated legacy apps that genuinely cannot run on a supported version, and ideally not exposed publicly. End-of-life versions no longer get upstream security patches, so plan to migrate those apps and remove the old version as soon as possible.
