{"id":4308,"date":"2026-07-10T10:32:46","date_gmt":"2026-07-10T10:32:46","guid":{"rendered":"https:\/\/ownwebservers.com\/kb\/?p=4308"},"modified":"2026-07-10T20:00:57","modified_gmt":"2026-07-10T20:00:57","slug":"php-8x-end-of-life-schedules-compatibility","status":"publish","type":"post","link":"https:\/\/ownwebservers.com\/kb\/php-8x-end-of-life-schedules-compatibility\/","title":{"rendered":"PHP 8.x End-of-Life Schedules & Compatibility: A Sysadmin’s Upgrade Guide"},"content":{"rendered":"

Every few weeks I get the same support ticket in some form: “My site suddenly broke after a server migration,” or “My host says I have to upgrade PHP but my plugin doesn’t work.” Underneath almost all of these is the same root cause\u2014a PHP version that’s either past its expiration date or a codebase that hasn’t kept pace with the language. PHP’s release cadence is predictable and well documented, yet the number of production servers still running unsupported interpreters is genuinely alarming.<\/p>\n

This guide walks through the PHP 8.x support timeline, explains what “end of life” actually means for a running server, and gets into the practical mechanics of installing and juggling multiple PHP versions with PHP-FPM. I’ll assume you manage real servers and care about not getting paged at 2 a.m. because a deprecation warning turned into a fatal error.<\/p>\n

Understanding the PHP Release Lifecycle<\/h2>\n

PHP follows a disciplined, time-based release model. A new minor version (8.1, 8.2, 8.3, and so on) drops roughly once a year, typically late in the calendar year. Each of those branches gets a fixed support window before the volunteer release managers stop shipping fixes for it. Knowing this schedule is half the battle\u2014it lets you plan upgrades on your own timeline instead of scrambling when a CVE lands.<\/p>\n

Active Support vs. Security-Only Support<\/h3>\n

There are two distinct phases in a PHP branch’s life, and conflating them is a common mistake.<\/p>\n

Active support<\/strong> is the first phase, lasting approximately two years. During this window the branch receives both bug fixes and security patches. If you report a reproducible bug in a function’s behavior, it can get fixed and backported into a point release.<\/p>\n

Security-only support<\/strong> follows for roughly one more year. Here the release managers only ship patches for confirmed security vulnerabilities. General bugs, quirky edge cases, and performance regressions won’t be addressed\u2014only things that could compromise a server. Once this phase ends, the branch is end of life<\/em> and receives nothing at all.<\/p>\n

The Roughly 3-Year Support Window Explained<\/h3>\n

Add those phases together and each minor release gets about three years of coverage from its initial stable release. That’s your planning horizon. If you’re standing up a new server today, choosing the newest stable branch buys you the maximum runway before you’re forced to touch it again. Choosing a branch that’s already 18 months old means you’re inheriting someone else’s countdown clock.<\/p>\n

The practical takeaway: never treat a PHP version as “set and forget.” Build the upgrade cadence into your maintenance calendar the same way you’d schedule OS patching or TLS certificate renewals.<\/p>\n

Current PHP 8.x End-of-Life Schedule<\/h2>\n

Here’s where each 8.x branch stands. Bookmark these dates\u2014they should drive your upgrade roadmap.<\/p>\n

PHP 8.0: Already End-of-Life (November 26, 2023)<\/h3>\n

PHP 8.0 crossed into end-of-life on November 26, 2023. It receives no further patches of any kind, including security fixes. If you’re still running 8.0 in production, you’re exposed to any vulnerability disclosed after that date with zero official remedy. This is not a “we’ll get to it next quarter” situation\u2014it’s a live risk that grows every time a new interpreter-level CVE is published. Migrate off 8.0 now.<\/p>\n

PHP 8.1: Security Support Until December 31, 2025<\/h3>\n

PHP 8.1 has already exited active support and is in its security-only phase, which ends December 31, 2025. It’s still safe to run today, but the window is closing. If you’re on 8.1, you have breathing room to test and plan, but I’d treat it as a version to move off of within your next planning cycle rather than something to sit on.<\/p>\n

PHP 8.2: Security Support Until December 31, 2026<\/h3>\n

PHP 8.2 receives security patches through December 31, 2026. This is a solid, mature choice for stability-focused deployments. Most major frameworks and CMS platforms have fully caught up to 8.2 at this point, so compatibility surprises are rare.<\/p>\n

PHP 8.3: Security Support Until December 31, 2027<\/h3>\n

PHP 8.3 is supported through December 31, 2027, making it the longest-lived branch among the well-established releases. For new deployments where you want a proven version with a long runway, 8.3 is the sweet spot right now.<\/p>\n

PHP 8.4: The Newest Stable Line (Released December 2024)<\/h3>\n

PHP 8.4 arrived in December 2024 as the current cutting-edge stable line. It brings new features and, importantly, some new deprecations you’ll want to audit for\u2014most notably the deprecation of implicitly nullable parameter types (declaring a parameter with a default of null<\/code> without explicitly marking the type nullable). If your codebase and its dependencies are actively maintained and you want the newest performance and syntax improvements, 8.4 is worth testing. For legacy applications, verify third-party library compatibility carefully before jumping.<\/p>\n

Why Running EOL PHP Is a Security Risk<\/h2>\n

Unpatched Vulnerabilities in Production<\/h3>\n

When a PHP branch goes end of life, the interpreter itself stops getting security fixes. That’s a different and more dangerous category of risk than an outdated application dependency. A vulnerability in PHP’s core\u2014say, in its handling of a particular stream wrapper, image parsing routine, or serialization path\u2014can potentially be exploited across every site running that interpreter, regardless of how well-written your application code is.<\/p>\n

I’ve seen people argue that a distro will “backport” fixes indefinitely. Some enterprise distributions do maintain their own patched builds for a while, but that’s a specific vendor commitment with its own end dates, not the same as upstream PHP support. Don’t assume you’re covered without confirming it explicitly.<\/p>\n

Compliance and Reputation Implications<\/h3>\n

If you handle payment data, PCI DSS requires that you run supported software with current security patches. An EOL PHP install is a straightforward audit failure. Beyond compliance, security scanners flag EOL runtimes routinely, and a client discovering an unsupported PHP version on their invoice-processing site is a conversation no hosting provider wants to have. The reputational cost of a breach traced back to a known-EOL interpreter is far higher than the cost of a planned upgrade.<\/p>\n

Installing Current PHP Versions on Your Server<\/h2>\n

Why Distro-Provided Packages Lag Behind Upstream<\/h3>\n

Long-term support Linux distributions prioritize stability over freshness. When you install php<\/code> from the default Ubuntu 22.04 or RHEL 9 repositories, you get whatever version was current when that distro release was frozen, plus vendor backports. That can leave you a full major-minor behind upstream, and once the distro itself ages, that PHP package can stagnate.<\/p>\n

For most production hosting, the answer is a trusted third-party repository that tracks upstream closely and packages multiple PHP versions side by side. Two are the de facto standards.<\/p>\n

Ond\u0159ej Sur\u00fd’s PPA for Ubuntu and Debian<\/h3>\n

Ond\u0159ej Sur\u00fd maintains the canonical PHP packaging for Debian and provides a PPA that carries every supported PHP version simultaneously. On Ubuntu:<\/p>\n

sudo add-apt-repository ppa:ondrej\/php\nsudo apt update\n\n# Install PHP 8.3 with FPM and common extensions\nsudo apt install php8.3-fpm php8.3-cli php8.3-mysql \n  php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip<\/code><\/pre>\n
On Debian, use the corresponding deb.sury.org<\/code> repository:<\/p>\n
sudo apt install -y apt-transport-https lsb-release ca-certificates curl\nsudo curl -sSL https:\/\/packages.sury.org\/php\/apt.gpg \n  -o \/etc\/apt\/trusted.gpg.d\/php.gpg\necho \"deb https:\/\/packages.sury.org\/php\/ $(lsb_release -sc) main\" \n  | sudo tee \/etc\/apt\/sources.list.d\/php.list\nsudo apt update<\/code><\/pre>\n
The beauty of this setup is that each version’s binaries and FPM services are namespaced by version (php8.2-fpm<\/code>, php8.3-fpm<\/code>), so they coexist cleanly. You switch the CLI default with update-alternatives<\/code>:<\/p>\n
sudo update-alternatives --config php<\/code><\/pre>\n
Remi’s Repository for RHEL, AlmaLinux, and Rocky<\/h3>\n
On the Red Hat side, Remi Collet’s repository is the trusted source. It integrates with the module system on modern EL releases. On AlmaLinux or Rocky 9:<\/p>\n
sudo dnf install https:\/\/dl.fedoraproject.org\/pub\/epel\/epel-release-latest-9.noarch.rpm\nsudo dnf install https:\/\/rpms.remirepo.net\/enterprise\/remi-release-9.rpm\n\n# Reset the default module and enable the version you want\nsudo dnf module reset php\nsudo dnf module enable php:remi-8.3\nsudo dnf install php php-fpm php-mysqlnd php-gd \n  php-mbstring php-xml php-curl php-zip<\/code><\/pre>\n
If you need genuinely parallel installs on EL (rather than one active module stream), Remi also ships versioned Software Collection\u2013style packages like php83<\/code> and php82<\/code> that install under \/opt\/remi\/<\/code> and can run independently. This is the approach to use when a single server must serve sites on different PHP versions simultaneously.<\/p>\n
Running Multiple PHP Versions with PHP-FPM<\/h2>\n
PHP-FPM (FastCGI Process Manager) is the standard deployment model today, and its single greatest operational advantage is that it lets you run multiple PHP versions concurrently on one host. Each version runs its own FPM master with its own pools, listening on its own socket. Your web server then routes each site to whichever socket it needs. No mod_php<\/code> version lock, no all-or-nothing decisions.<\/p>\n
PHP-FPM with Nginx<\/h3>\n
Nginx doesn’t embed PHP\u2014it proxies FastCGI requests to an FPM socket. That makes per-site version selection trivially a matter of pointing at the right socket. Say you have a legacy site that must stay on 8.2 and a modern one on 8.3.<\/p>\n
# \/etc\/nginx\/sites-available\/legacy.example.com\nserver {\n    listen 80;\n    server_name legacy.example.com;\n    root \/var\/www\/legacy;\n    index index.php;\n\n    location ~ .php$ {\n        include fastcgi_params;\n        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n        fastcgi_pass unix:\/run\/php\/php8.2-fpm.sock;\n    }\n}<\/code><\/pre>\n
# \/etc\/nginx\/sites-available\/modern.example.com\nserver {\n    listen 80;\n    server_name modern.example.com;\n    root \/var\/www\/modern;\n    index index.php;\n\n    location ~ .php$ {\n        include fastcgi_params;\n        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n        fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n    }\n}<\/code><\/pre>\n
For proper isolation, give each site its own FPM pool running under a dedicated user. Create a pool file such as \/etc\/php\/8.3\/fpm\/pool.d\/modern.conf<\/code>:<\/p>\n
[modern]\nuser = modern\ngroup = modern\nlisten = \/run\/php\/php8.3-modern.sock\nlisten.owner = www-data\nlisten.group = www-data\npm = dynamic\npm.max_children = 10\npm.start_servers = 2\npm.min_spare_servers = 1\npm.max_spare_servers = 4<\/code><\/pre>\n
Then point that vhost at \/run\/php\/php8.3-modern.sock<\/code>. Per-pool users mean a compromise or runaway process in one site can’t trivially read another site’s files\u2014a hosting security fundamental.<\/p>\n
PHP-FPM with Apache via mod_proxy_fcgi<\/h3>\n
Apache traditionally used mod_php<\/code>, which locks the entire server to one PHP version and doesn’t play nicely with the event or worker MPMs. The modern approach mirrors Nginx: run Apache with mod_proxy_fcgi<\/code> and proxy PHP requests to FPM sockets. Enable the required modules:<\/p>\n
sudo a2enmod proxy proxy_fcgi setenvif\nsudo a2enconf php8.3-fpm   # if provided by the package<\/code><\/pre>\n
Then per vhost, use a FilesMatch<\/code> block with SetHandler<\/code> to route to the version you want:<\/p>\n
<VirtualHost *:80>\n    ServerName legacy.example.com\n    DocumentRoot \/var\/www\/legacy\n\n    <FilesMatch \".php$\">\n        SetHandler \"proxy:unix:\/run\/php\/php8.2-fpm.sock|fcgi:\/\/localhost\"\n    <\/FilesMatch>\n<\/VirtualHost>\n\n<VirtualHost *:80>\n    ServerName modern.example.com\n    DocumentRoot \/var\/www\/modern\n\n    <FilesMatch \".php$\">\n        SetHandler \"proxy:unix:\/run\/php\/php8.3-fpm.sock|fcgi:\/\/localhost\"\n    <\/FilesMatch>\n<\/VirtualHost><\/code><\/pre>\n
Run Apache with the event<\/code> MPM in this configuration for far better concurrency than the prefork MPM that mod_php<\/code> forces on you. It’s a meaningful performance win on top of the version flexibility.<\/p>\n
Testing Compatibility Before You Switch<\/h2>\n
Flipping a live site’s PHP version without testing is how you turn a routine upgrade into an outage. Each major version jump has removed or deprecated behaviors that older code relies on. PHP 8.0 pruned a large batch of long-deprecated features. PHP 8.1 deprecated passing null<\/code> to non-nullable parameters of internal functions\u2014something surprisingly common in older code that leaned on loose typing. PHP 8.4 deprecates implicitly nullable parameter types. Any of these can escalate from a log warning to a fatal error in a future version.<\/p>\n
Three tools belong in your upgrade workflow:<\/p>\n