Tutorials · July 10, 2026 · 16 min read

PHP 8.x End-of-Life Schedules & Compatibility: A Sysadmin’s Upgrade Guide

Isometric server rack timeline with PHP elephant mascots for versions 8.0 to 8.4 on a calendar path, older ones fading at end-of-life

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—a 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.

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.

Understanding the PHP Release Lifecycle

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—it lets you plan upgrades on your own timeline instead of scrambling when a CVE lands.

Active Support vs. Security-Only Support

There are two distinct phases in a PHP branch’s life, and conflating them is a common mistake.

Active support 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.

Security-only support 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—only things that could compromise a server. Once this phase ends, the branch is end of life and receives nothing at all.

The Roughly 3-Year Support Window Explained

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.

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.

Current PHP 8.x End-of-Life Schedule

Here’s where each 8.x branch stands. Bookmark these dates—they should drive your upgrade roadmap.

PHP 8.0: Already End-of-Life (November 26, 2023)

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—it’s a live risk that grows every time a new interpreter-level CVE is published. Migrate off 8.0 now.

PHP 8.1: Security Support Until December 31, 2025

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.

PHP 8.2: Security Support Until December 31, 2026

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.

PHP 8.3: Security Support Until December 31, 2027

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.

PHP 8.4: The Newest Stable Line (Released December 2024)

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—most notably the deprecation of implicitly nullable parameter types (declaring a parameter with a default of null 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.

Why Running EOL PHP Is a Security Risk

Unpatched Vulnerabilities in Production

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—say, in its handling of a particular stream wrapper, image parsing routine, or serialization path—can potentially be exploited across every site running that interpreter, regardless of how well-written your application code is.

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.

Compliance and Reputation Implications

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.

Installing Current PHP Versions on Your Server

Why Distro-Provided Packages Lag Behind Upstream

Long-term support Linux distributions prioritize stability over freshness. When you install php 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.

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.

Ondřej Surý’s PPA for Ubuntu and Debian

Ondřej Surý maintains the canonical PHP packaging for Debian and provides a PPA that carries every supported PHP version simultaneously. On Ubuntu:

sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.3 with FPM and common extensions
sudo apt install php8.3-fpm php8.3-cli php8.3-mysql 
  php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip

On Debian, use the corresponding deb.sury.org repository:

sudo apt install -y apt-transport-https lsb-release ca-certificates curl
sudo curl -sSL https://packages.sury.org/php/apt.gpg 
  -o /etc/apt/trusted.gpg.d/php.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" 
  | sudo tee /etc/apt/sources.list.d/php.list
sudo apt update

The beauty of this setup is that each version’s binaries and FPM services are namespaced by version (php8.2-fpm, php8.3-fpm), so they coexist cleanly. You switch the CLI default with update-alternatives:

sudo update-alternatives --config php

Remi’s Repository for RHEL, AlmaLinux, and Rocky

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:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm

# Reset the default module and enable the version you want
sudo dnf module reset php
sudo dnf module enable php:remi-8.3
sudo dnf install php php-fpm php-mysqlnd php-gd 
  php-mbstring php-xml php-curl php-zip

If you need genuinely parallel installs on EL (rather than one active module stream), Remi also ships versioned Software Collection–style packages like php83 and php82 that install under /opt/remi/ and can run independently. This is the approach to use when a single server must serve sites on different PHP versions simultaneously.

Running Multiple PHP Versions with PHP-FPM

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 version lock, no all-or-nothing decisions.

PHP-FPM with Nginx

Nginx doesn’t embed PHP—it 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.

# /etc/nginx/sites-available/legacy.example.com
server {
    listen 80;
    server_name legacy.example.com;
    root /var/www/legacy;
    index index.php;

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

# /etc/nginx/sites-available/modern.example.com
server {
    listen 80;
    server_name modern.example.com;
    root /var/www/modern;
    index index.php;

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

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:

[modern]
user = modern
group = modern
listen = /run/php/php8.3-modern.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4

Then point that vhost at /run/php/php8.3-modern.sock. Per-pool users mean a compromise or runaway process in one site can’t trivially read another site’s files—a hosting security fundamental.

PHP-FPM with Apache via mod_proxy_fcgi

Apache traditionally used mod_php, 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 and proxy PHP requests to FPM sockets. Enable the required modules:

sudo a2enmod proxy proxy_fcgi setenvif
sudo a2enconf php8.3-fpm   # if provided by the package

Then per vhost, use a FilesMatch block with SetHandler to route to the version you want:

<VirtualHost *:80>
    ServerName legacy.example.com
    DocumentRoot /var/www/legacy

    <FilesMatch ".php$">
        SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

<VirtualHost *:80>
    ServerName modern.example.com
    DocumentRoot /var/www/modern

    <FilesMatch ".php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

Run Apache with the event MPM in this configuration for far better concurrency than the prefork MPM that mod_php forces on you. It’s a meaningful performance win on top of the version flexibility.

Testing Compatibility Before You Switch

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 to non-nullable parameters of internal functions—something 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.

Three tools belong in your upgrade workflow:

PHPCompatibility — a ruleset for PHP_CodeSniffer that statically scans your code and reports which features break on a target version. Run it against your codebase specifying the version you’re moving to and it flags every incompatibility it finds.
Rector — automated refactoring that can rewrite code to conform to a newer PHP version, handling many deprecations mechanically instead of by hand.
PHPStan — static analysis that catches type-related bugs and dubious constructs, which tend to surface exactly at version boundaries.

A typical PHPCompatibility invocation targeting PHP 8.3:

phpcs --standard=PHPCompatibility 
  --runtime-set testVersion 8.3 
  /var/www/modern/src

Don’t forget your dependencies. Run composer why-not php 8.3 to see which packages block the target version, and update them first. And remember that CMS platforms carry their own requirements—WordPress runs on PHP 7.4 and up but genuinely performs better on PHP 8.x, and many plugins lag behind core. Test the whole stack, not just your custom code.

Best Practices

Track EOL dates in your maintenance calendar. Schedule the upgrade before the security-support deadline, not on the day it lands.
Always stage first. Clone the site to a staging environment on the target PHP version and run your full test suite plus manual smoke tests before touching production.
Use versioned FPM pools with dedicated users. One pool per site under its own UID gives you both isolation and the ability to tune resources per workload.
Run static analysis in CI. Wire PHPCompatibility and PHPStan into your pipeline so incompatibilities are caught before deployment, not after.
Prefer the newest well-supported branch for new builds. Choosing PHP 8.3 or 8.4 today maximizes your support runway.
Keep OPcache tuned and warm. After switching versions, verify OPcache settings—stale or misconfigured cache is a frequent source of “it works but it’s slow” complaints post-upgrade.
Match CLI and FPM versions deliberately. Cron jobs and queue workers often run under the CLI SAPI; make sure they use the same version as the web-facing FPM pool.
Document your socket-to-site mapping. When you’re running four PHP versions across dozens of vhosts, a simple reference table saves real debugging time.

Troubleshooting

Most PHP version problems fall into a handful of recognizable patterns. Here are the ones I encounter most often and how to resolve them.

Symptom	Likely Cause	Fix
502 Bad Gateway from Nginx after switching versions	Config points to an FPM socket that doesn’t exist or isn’t running	Confirm the correct `php8.x-fpm` service is active and the `fastcgi_pass` socket path matches the pool’s `listen` directive
Fatal error: Call to undefined function	Required extension not installed for the new PHP version	Install the version-specific extension package (e.g. `php8.3-gd`) and restart the matching FPM service
Deprecation warnings flooding the error log	Code uses features deprecated in the new version (null-to-non-nullable, implicit nullable types)	Run PHPCompatibility to locate them and Rector to remediate; suppress in logs only as a temporary measure
CLI shows one version, website another	CLI default and FPM pool are on different branches	Set the CLI default with `update-alternatives --config php` (Debian) or the correct module stream (EL)
Apache serves raw PHP source instead of executing it	`mod_proxy_fcgi` not enabled or `SetHandler` misconfigured	Enable `proxy_fcgi`, verify the `FilesMatch` block and socket path, then reload Apache
Permission denied writing uploads or cache after version change	New FPM pool runs as a different user than the old one	Align the pool’s `user`/`group` with file ownership, or fix directory ownership to match the pool user
Changes to code don’t take effect	OPcache is serving stale bytecode	Restart the FPM service or reset OPcache; check `opcache.validate_timestamps` in production configs

Conclusion

PHP’s support lifecycle isn’t a mystery—it’s a published, predictable schedule you can plan around. PHP 8.0 is already gone and should be off every production server. PHP 8.1 is on borrowed time with its security window closing at the end of 2025. PHP 8.2, 8.3, and 8.4 give you supported, well-tested options with progressively longer runways, and 8.3 in particular hits a nice balance of maturity and longevity.

The tooling to do this safely is mature and free. Third-party repositories from Ondřej Surý and Remi Collet let you install and run any supported version, PHP-FPM lets those versions coexist on a single host with per-site pools, and PHPCompatibility, Rector, and PHPStan take the guesswork out of code auditing. Combine staged testing with a maintenance calendar built around EOL dates and PHP upgrades become a routine chore rather than an emergency.

Treat your PHP version like any other piece of critical infrastructure: keep it patched, keep it supported, and never let it drift past end of life on a live server. Your future self—and your clients—will thank you.

Frequently Asked Questions

When does each PHP 8.x version reach end-of-life?

PHP 8.0 already reached end-of-life on November 26, 2023, and no longer receives security fixes. PHP 8.1 has security support until December 31, 2025, PHP 8.2 until December 31, 2026, and PHP 8.3 until December 31, 2027. PHP 8.4, released in December 2024, is the newest stable line with the longest remaining support window.

How long is each PHP version supported?

Each PHP minor release follows a roughly three-year lifecycle: about two years of active bug-fix support followed by one year of security-only fixes. During active support, both bugs and security issues are patched, while the security-only phase addresses only critical vulnerabilities. After that final year, the branch reaches end-of-life and receives no further updates.

Is it dangerous to run an end-of-life PHP version in production?

Yes. Once a PHP version reaches end-of-life it no longer receives security patches, so any newly discovered vulnerabilities remain unfixed and exploitable. This exposes your sites to compromise and can create compliance problems for standards like PCI DSS. It can also damage your reputation and that of your hosting provider if a breach occurs.

How can I install a current PHP version when my distro's package is outdated?

Distro-provided PHP packages often lag well behind upstream releases. On Ubuntu and Debian, admins commonly use Ondřej Surý’s PPA to install current versions, while on RHEL, AlmaLinux, and Rocky Linux, Remi’s repository is the trusted choice. Both are widely used, well-maintained, and support installing multiple PHP versions side by side.

Can I run multiple PHP versions on the same server?

Yes, PHP-FPM makes this straightforward by running separate FPM pools for each version. With Nginx, you map each site to the appropriate FPM socket or port, and with Apache you can do the same via mod_proxy_fcgi. This lets you keep legacy sites on older runtimes while migrating others to newer, supported versions.

How do I test my code for compatibility before upgrading PHP?

Use automated tooling to audit your codebase before switching the live runtime. PHPCompatibility, a PHP_CodeSniffer ruleset, flags version-specific issues, while PHPStan performs static analysis and Rector can automate many code fixes. Test in a staging environment first, since changes like PHP 8.1’s null-parameter deprecations and PHP 8.4’s implicitly nullable parameter deprecations can break older code.