Remi stopped building PHP for CentOS 7 in June 2024. GetPageSpeed provides Remi PHP extended support for CentOS 7: drop-in compatible packages with the same names, paths and ABI, so your existing PHP keeps receiving security updates through plain yum update. No migration, no new install prefix, no switching sites to a different PHP build.
This page explains what happened to Remi PHP on EL7, what “drop-in compatible” means in practice, and how this approach compares with TuxCare and Cybertrust extended support. If you landed here because of the PHP2Shell emergency, the step-by-step fix lives in PHP2Shell on CentOS 7.
Remi PHP extended support in one command
CentOS 7 servers run Remi’s PHP in one of two shapes, and the GetPageSpeed repository ships both for every version from 5.4 to 8.4. Check which shape you have:
rpm -qa 'php*-common' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n'
Base-name packages (for example php-common-7.4.33-15.el7.remi, installed from remi-php74) upgrade in place from the channel matching your version:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum --enablerepo=getpagespeed-extras-php74 upgrade 'php-*'
systemctl restart php-fpm
Replace php74 with your version: php54, php56, php70, php71, php72, php73, php80, php81, php82, php83 or php84.
Software collections (for example php74-php-common-7.4.33-15.el7.remi, from remi-safe) upgrade from the always-enabled main repository, no channel needed:
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum upgrade 'php74-php*'
systemctl restart php74-php-fpm
Afterwards, php -v prints Built by GetPageSpeed LLC with the exact release under the copyright line. On Debian and Ubuntu, the equivalent story for Surý-style packages is covered in PHP2Shell on Ubuntu and Debian.
What happened to Remi PHP on CentOS 7
The Remi repository has been the de-facto source of PHP on Enterprise Linux for over a decade, and it remains excellent on EL8, EL9 and EL10. On EL7, however, Remi stopped building when CentOS 7 reached end of life in June 2024.
The consequence crept in quietly. yum update kept exiting cleanly, so monitoring stayed green, while the installed PHP silently froze: the EL7 builds stopped at PHP 8.2.20 and 8.3.8, and the older branches stopped receiving the backports Remi kept publishing for newer distributions. When the critical PHP2Shell vulnerability (CVE-2026-109618 and CVE-2026-109619) was disclosed in October 2026, php.net itself told Remi EL7 users that the repository would not have updates and that they should build from source.
A release ending in .el7.remi is a 2024-or-earlier build. Searching for your exact version string, such as 7.4.33-15.el7.remi? That is Remi’s last EL7 build of PHP 7.4, and it predates every PHP security fix since. The per-version pages under Everpatch for CentOS 7 list each currently shipped patched release and the exact CVEs it carries.
What “drop-in compatible” means
GetPageSpeed PHP builds for EL7 are independently maintained, starting from the sources Remi still maintains for newer Enterprise Linux releases wherever those exist, and are drop-in compatible with the Remi package layout:
- Same package names, both shapes. Base-name
php-*packages andphpNN-php-*software collections, exactly as Remi ships them.yum upgradeswaps them in place; there is no new install prefix and no per-site switching. - Same ABI and SONAMEs. PECL extensions and ionCube Loader keep loading without a rebuild. Validation confirms the loaded module list is identical before and after the upgrade.
- Same configuration files and service names.
php-fpmstaysphp-fpm,php74-php-fpmstaysphp74-php-fpm, andscl enable php74keeps working. - Reversible.
yum downgradereturns you to the Remi packages at any time.
Updates beyond the headline CVEs are included: the 2024 to 2026 security fixes that EL7 never received are carried into every branch, and new PHP security batches are ported as they appear. Subscribers also receive CVE advisory emails, so you know when it is time to yum upgrade.
Extended support is a bridge, not a destination. If a migration to EL9 or EL10 is realistically months away, Remi’s own current builds await you there and nothing here applies. The in-place approach exists for the servers where that migration keeps slipping: the application is certified against one PHP version, the vendor is gone, or the fleet is too large to move this year. Those servers need patches where they stand.
How this compares with TuxCare and Cybertrust
Searching for Remi PHP extended support surfaces three vendors. They solve the problem in structurally different ways, and the right choice depends on how much of your existing deployment you want to keep.
| GetPageSpeed | TuxCare ELS for PHP | Cybertrust Japan | |
|---|---|---|---|
| Delivery model | In-place yum upgrade of your existing Remi-compatible packages |
Separate alt-php builds under /opt/alt/php[version]; each site is switched to them |
Resells TuxCare ELS for PHP; its own extended support covers base OS packages |
| Existing Remi deployment | Kept as is: same names, paths, configs, extensions | Replaced: new prefix, sites migrated via PHP Selector | Base OS PHP only (5.4); Remi-style versions go through the TuxCare resale |
| PHP versions on EL7 | 5.4 to 8.4 (every version CentOS 7 can run); older on request | 5.2 to 8.5 listed | Per TuxCare resale |
| Getting started | Install immediately; evaluation needs no signup | License key required first | License key issuance takes about 5 business days |
| Support | Priority support on Ultra | Per their ELS terms | 2 technical questions per contract, replies targeted within 2 weeks |
| Price | Ultra: $500/year, up to 10 servers | Not published | OS extended support: ¥120,000 (about $760) per server/year |
Sources: TuxCare’s ELS for PHP documentation (alt-php install location, versions, platforms), TuxCare’s CentOS 7 ELS page (OS-level scope; PHP handled by the separate Runtimes product), and Cybertrust’s published TuxCare ELS PHP emergency pack page and CentOS extended support catalog (license key timeline, question limit, reply target, per-server pricing and the June 2028 coverage date), all as published in November 2026. Yen converted at November 2026 rates.
Whichever option you evaluate, the structural question is the same: what happens to the PHP deployment you already run? TuxCare’s own CentOS 7 extended support covers the OS layer and hands PHP minor versions to the separate alt-php product, and Cybertrust’s PHP answer is that same product, resold. Both of those paths end with every site migrated to a new PHP build tree. The GetPageSpeed approach is the only one of the three that updates the PHP you already run, in place, under its existing package names. Need a version outside the published range, such as PHP 5.2? Contact us: older builds are provided on request.
If your servers run Remi PHP today, the honest comparison is between migrating every site to a new PHP build tree and running one yum upgrade. For a feature-by-feature breakdown, see Everpatch vs TuxCare ELS for PHP.
Evaluate first, pay when it works
The packages install from the public GetPageSpeed repository with no signup, so the evaluation is the install itself: upgrade a staging server, confirm php -v, run your test suite. Personal, development and evaluation use is free under the repository terms.
Commercial production use requires GetPageSpeed Ultra ($500/year, up to 10 servers running your own services). Every new PHP CVE has to be ported again to branches upstream abandoned years ago; Ultra funds that work and covers the full GetPageSpeed repository of NGINX builds and modules for CentOS 7 as well. Administering servers for clients, or more than 10? GetPageSpeed Fleet starts at $800/year. Organizations that need a contractual SLA or purchase-order procurement use Enterprise.
Get Ultra: $500/year, 10 servers Fleet for client servers
FAQ
Can I keep my existing Remi packages and configuration?
Yes. That is the point of the drop-in approach: the GetPageSpeed builds carry the same package names, configuration files, ABI and service names as the Remi packages they replace, in both the base-name and software-collection shapes. yum downgrade reverses the upgrade if you ever need it.
Is this a copy of the Remi repository?
No. It is an independently maintained set of PHP builds for EL7, drop-in compatible with the Remi package layout. Where Remi still maintains sources for newer Enterprise Linux releases, those fixes are carried to EL7; where upstream published nothing, as with PHP 7.3 and older during PHP2Shell, GetPageSpeed ports the fixes itself.
Which PHP versions are covered on CentOS 7?
Every version a CentOS 7 server can run: 5.4 (the stock build), 5.6, 7.0 through 7.4, and 8.0 through 8.4, each in both package shapes. How to Install PHP 8.5 on CentOS 7 covers going newer than Remi ever did, and older versions such as PHP 5.2 are provided on request via contact.
How do I check whether my current PHP is still receiving updates?
Run rpm -qa 'php*-common'. A release ending in .el7.remi means the last update predates June 2024. Paste your package list into the free PHP2Shell checker for a per-package verdict, or install CVEfox for a one-command scan that understands vendor backports.
Conclusion
Remi PHP on CentOS 7 stopped receiving updates in June 2024, and the gap only widens with every new PHP security batch. Remi PHP extended support that replaces your PHP tree trades one migration for another; extended support that updates your existing packages in place is a single yum upgrade. That is what the GetPageSpeed repository ships, for every PHP version CentOS 7 can run, free to evaluate today.
Patched PHP is one layer of an EOL server. The NGINX in front of it and the rest of the stack drift too, one config change at a time. GetPageSpeed Amplify runs scheduled gixy scans across every host and ties findings to live NGINX runtime metrics. Drop-in compatible with the deprecated nginx-amplify-agent (EOL January 2026).
Running these servers for a business? GetPageSpeed Ultra ($500/year, up to 10 servers) keeps them covered for the next EOL PHP CVE, with the full GetPageSpeed repository included.