PHP 8.3 and 8.4 on a Server: New Features and Upgrade Timing

PHP 8.3 shipped in late 2023, and PHP 8.4 followed a year later. Both versions are already available on most servers with cPanel and ISPmanager 6, yet many projects still run on PHP 8.1 out of pure inertia. Let's look at what actually changed and whether it is worth upgrading right now.

What is new in PHP 8.3 and PHP 8.4

PHP 8.3 added typed class constants, the #[Override] attribute for controlling method overrides, and the json_validate() function, which checks whether JSON is well-formed without parsing the whole structure into memory. This noticeably speeds up validation of incoming API requests.

PHP 8.4 went further: it introduced property hooks (getters and setters declared right inside the property), asymmetric visibility (a public readonly property can now be public for reads and private for writes), and new array functions — array_find(), array_any(), array_all(). For more on strict typing, which pairs well with these additions, see the article on strict_types in production.

How property hooks work in practice

Previously, validating a value on write required a separate setter method. Property hooks remove that layer:

class Product {
    public int $price {
        set {
            if ($value < 0) {
                throw new InvalidArgumentException('Price cannot be negative');
            }
            $this->price = $value;
        }
    }
}

The code gets shorter, and IDEs and static analyzers see the real type of the property instead of guessing it from docblocks.

PHP version support timelines

Every PHP version gets two years of active support with bug fixes and one more year of security-only patches. After that the version is considered outdated and updates stop.

What to watch for during an upgrade

Some changes in 8.3 and 8.4 break old code that relied on PHP's loose behavior. Before upgrading, check:

• Implicit nullable types in function signatures — in PHP 8.4 such declarations are deprecated and require an explicit ?type.
• Dynamic class properties without the #[AllowDynamicProperties] attribute — they have been forbidden since PHP 8.2.
• PECL extensions that have not been updated for more than two years — some of them break on the new Zend Engine.
• Composer libraries with a hard upper PHP version bound in composer.json — they will need an update or a replacement.

How to check and switch the PHP version on a server

On Ubuntu and Debian, PHP versions are switched with update-alternatives, and for sites behind Nginx and PHP-FPM — through the pool in the virtual host config. First install the new version next to the old one without removing it:

php -v
sudo apt install php8.4 php8.4-fpm php8.4-mysql php8.4-mbstring
sudo update-alternatives --set php /usr/bin/php8.4
sudo systemctl restart php8.4-fpm

For keeping several versions at once and switching them per virtual host, see the article on multiple PHP versions on one server. The list of extensions needed for a specific framework is easier to collect from the guide on installing PHP extensions.

Is it worth upgrading: a checklist

Upgrading the PHP version is not a single click but a compatibility check. The order of steps is:

1. Deploy a copy of the project to staging with the new PHP version and run the tests, or at least the main scenarios, by hand.
2. Run composer install and make sure every dependency supports the chosen version without compatibility warnings.
3. Switch PHP-FPM to the new version and enable JIT in OPcache — the speed gain on CPU-intensive tasks is visible from the very first requests.

Frequently asked questions

How to upgrade from PHP 8.3 to PHP 8.4 without taking the site down during the switch?

The new version is best installed alongside the old one instead of removing it right away, with the project first tested on a staging copy. After composer install, make sure every dependency supports the new version without warnings, then switch the PHP-FPM pool to PHP 8.4 — that way, rolling back to the previous version stays instant if something breaks.

Which changes most often break old code when moving from PHP 8.3 to PHP 8.4?

The main culprit is implicit nullable types in function signatures: in PHP 8.4 that notation is deprecated and needs an explicit question mark before the type. Also worth checking in advance are old pecl extensions, dynamic class properties missing the special attribute, and Composer libraries with a hard upper bound on the supported PHP version.

Is it fine to keep running PHP 8.1 until there is time for a proper upgrade?

Technically the site keeps working with no visible change: active support for PHP 8.1 has already ended, and the security-only patch phase is winding down too. That means newly found vulnerabilities will stop getting fixed at all, leaving the server gradually unprotected against fresh problems — a reason to plan the move rather than put it off further.

Does JIT in OPcache have to be turned on right away when moving to a new PHP version?

No, that is not a required step for running the new version, just a separate recommendation from the post-upgrade checklist. Most ordinary sites are limited by database or network speed rather than CPU computation, so the gain from JIT there is barely noticeable. Enabling it mainly helps CPU-heavy tasks, where the speed boost shows up from the very first requests.