PHP 7.4 on Ubuntu 26.04: yes, but only to move on
4 min read
Old PHP apps are a fact of life. How Zefily runs PHP 7.3 to 8.1 on the newest Ubuntu, what keeps them reasonably safe, and why the goal is still to upgrade.
Every agency has one. The client site built in 2019 on PHP 7.4, with a plugin nobody dares to update and a custom theme written by someone who left years ago. It works, the client is happy, and nobody has the budget to rewrite it this quarter.
Meanwhile, the server it runs on is getting old, and the new one you would like to move to runs Ubuntu 26.04, which ships with PHP 8.5 and nothing older. Until recently that meant: keep the old server alive, or rewrite the site first.
Neither is great. So we did something about it.
In short
- Zefily runs PHP 7.3–8.4 on Ubuntu 26.04 next to 8.5, on amd64 and arm64, with nginx or OpenLiteSpeed.
- 8.2–8.4 are built from php.net releases; 7.3–8.1 from Ondřej Surý's sources with his OpenSSL 3 and security patches.
- Each site runs as its own Linux user in its own PHP pool, limited by
open_basedir. - PHP 7.3–8.1 get no fixes from the PHP project any more: use them to move legacy apps, then upgrade.
What changed
Zefily now runs PHP 7.3, 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4 on Ubuntu 26.04, next to 8.5, on both amd64 and arm64 servers, with nginx and with OpenLiteSpeed.
On Ubuntu 24.04 and Debian, older PHP versions have long come from Ondřej Surý's well-known repositories. Ondřej maintains the PHP packages for Debian and Ubuntu, and keeps backporting security fixes to versions that PHP itself no longer supports. At the time of writing, his repository does not yet cover Ubuntu 26.04, so we build those versions ourselves:
- 8.2 to 8.4 from the newest php.net release of each branch,
- 7.3 to 8.1 from Ondřej's sources, with his patches. They bring OpenSSL 3 support (which those versions never had upstream) and the security fixes he keeps backporting after the end of life.
The packages are signed and served from our own APT repository, and automatic updates install new builds as they come. When Ondřej's repository supports the new Ubuntu, servers can move to it and our packages become the fallback.
How an old version is kept in its corner
Running an old PHP version is a risk. The question is how much of the server that risk can reach. In Zefily, every site runs:
- as its own Linux user, with its own home and file permissions,
- in its own PHP pool (PHP-FPM, or LSPHP on OpenLiteSpeed where LiteSpeed builds that version), with
open_basedirlimiting it to its own directories, - with a security baseline of PHP settings applied to every version on the server, old ones included,
- behind the server's firewall, CrowdSec and, if you turn it on, the web application firewall.
So a vulnerable plugin on the 7.4 site is a problem for that site, not an open door to the WordPress next to it on PHP 8.4.
Old is not the same as safe
We want to be very clear here, because it is easy to read "supported" as "fine". PHP 7.3 to 8.1 no longer receive security fixes from the PHP project. PHP 8.2 joins them at the end of 2026. Ondřej's backports are excellent work, but they are one person's effort to cover the most important issues, not a full security team.
That is why the panel marks these versions as past their end of life, hides them behind Show older versions, and includes them in your weekly digest. We think of them as a bridge: get the old site off the old server today, isolated, patched as well as it can be, and then plan the upgrade.
A practical path
- Move first. Create the site on the new server with the PHP version it needs today. Copy the files and the database, and test it on its free
zefily.appaddress before you switch the DNS. - Turn the safety on. Put the site behind the WAF in detect only mode for a week, then block. Keep backups daily.
- Upgrade in steps. Clone the site to a staging copy and raise PHP one version at a time: 7.4 → 8.0 → 8.1 → 8.2 → 8.4. Each step usually breaks a few things, and they are much easier to fix one version at a time than all at once.
- Retire the old version. When no site uses it any more, remove it from the server. Zefily refuses to remove a version that a site still uses, so you cannot pull the floor from under a site by accident.
The honest summary
Old PHP is technical debt with interest. We cannot make it go away, but we can make it cheaper to carry while you pay it off: on a current operating system, isolated, patched where patches exist, and clearly labelled.
Frequently asked questions
Can I install PHP 7.4 on Ubuntu 26.04?
Ubuntu 26.04 itself ships only PHP 8.5. Zefily installs PHP 7.3 to 8.4 there from its own signed packages, on amd64 and arm64, with nginx or OpenLiteSpeed.
Is it safe to run PHP 7.4 in 2026?
Not fully. PHP 7.4 no longer receives fixes from the PHP project; Ondřej Surý's backported patches cover the most important issues. Run it isolated, behind a web application firewall, and only as a bridge to a newer version.
Where do the old PHP packages come from?
On Ubuntu 24.04 and Debian, from Ondřej Surý's repositories. On Ubuntu 26.04, which his repository does not cover yet, Zefily builds them: 8.2–8.4 from php.net, 7.3–8.1 from his sources and patches.
When does PHP 8.2 reach end of life?
PHP 8.2 stops receiving security fixes from the PHP project at the end of 2026, joining 7.3 to 8.1.
How should I upgrade an old PHP site?
Move it first with the version it needs, then clone it to a staging copy and raise PHP one version at a time (7.4 → 8.0 → 8.1 → 8.2 → 8.4), fixing what breaks at each step.
See supported systems and Web stack for the full version matrix.