Laravel and Symfony PHP Requirements in Late 2026: Support Windows and Upgrade Order

A framework sets two clocks for your application: the PHP versions it will run on, and how long it receives bug and security fixes. PHP itself has a third clock. When any of the three runs out, the application is running on unsupported code. This guide lays out the current Laravel and Symfony positions, taken from each project's official release pages on 31 October 2026, and an upgrade order that avoids getting stuck.

PHP's own calendar

From php.net: PHP 8.2 receives security fixes until 31 December 2026, PHP 8.3 until 31 December 2027, PHP 8.4 until 31 December 2028 and PHP 8.5 until 31 December 2029. PHP 8.1 reached end of life on 31 December 2025. For distribution packages, Debian 13 (trixie) ships PHP 8.4, Debian 12 (bookworm) ships PHP 8.2, Ubuntu 24.04 ships PHP 8.3 and Ubuntu 22.04 ships PHP 8.1.

Laravel

Laravel publishes a major release roughly every year in the first quarter. Its support policy gives each major release 18 months of bug fixes and two years of security fixes:

What this means in practice:

• Laravel 11 and older are out of support. They no longer receive security fixes from the Laravel team.
• Laravel 12 is security-only until 24 February 2027. If it runs on PHP 8.2, two deadlines arrive close together: PHP 8.2 at the end of December 2026 and Laravel 12 in February 2027.
• Laravel 13 drops PHP 8.2. Its upgrade guide asks you to move laravel/framework to ^13.0 along with related packages such as laravel/tinker ^3.0 and phpunit/phpunit ^12.0.

Symfony

Symfony follows a time-based model: minor versions in May and November, a major version every two years, and a long-term support (LTS) release at the end of each major line. The branches maintained today are:

Symfony 8.0 already reached its end in July 2026, and Symfony 8.2 is scheduled for November 2026, also requiring PHP 8.4 or higher. Two consequences stand out. First, the whole Symfony 8 line needs PHP 8.4, so it cannot run on the PHP 8.2 that Debian 12 ships or the PHP 8.3 that Ubuntu 24.04 ships. Second, non-LTS minors such as 8.1 are supported for only about eight months; teams that cannot upgrade twice a year are better served by the LTS line, which today means 7.4.

Read your project's actual constraints

The framework tables are the starting point; your composer.lock decides. These Composer commands answer the practical questions:

php artisan --version           # Laravel
php bin/console --version       # Symfony
composer show laravel/framework # or symfony/http-kernel
composer prohibits php 8.4      # which packages block PHP 8.4, and why
composer check-platform-reqs    # does this server's PHP and extensions satisfy the lock file?

composer prohibits php 8.4 lists every installed package whose constraints exclude that PHP version, which is the fastest way to size a PHP upgrade. check-platform-reqs deliberately ignores Composer's config.platform setting and checks the real PHP binary and extensions, so run it on the server, with the same PHP version the website uses.

If developers run a newer PHP locally than production, pin the target platform in composer.json so composer update never picks packages that production cannot run:

{
    "config": {
        "platform": {
            "php": "8.3.0"
        }
    }
}

Composer's documentation warns that this setting makes it trust the stated version instead of the real one, which is why it recommends running check-platform-reqs as part of deployment.

A safe upgrade order

1. Move PHP first, to a version both your current and your target framework support. Laravel 12 runs on 8.2 to 8.5 and Laravel 13 on 8.3 to 8.5, so take a Laravel 12 application from PHP 8.2 to 8.3 or 8.4, deploy, and only then upgrade the framework. For Symfony, 6.4 to 7.4 needs at least PHP 8.2, and any step into 8.x needs PHP 8.4.
2. Upgrade the framework in a branch. Update the constraints the upgrade guide names, run composer update, then your test suite and static checks.
3. Deploy to staging with production's PHP version and extensions. Run composer check-platform-reqs there.
4. Restart long-running workers on every deploy. Laravel queue workers keep old code in memory until php artisan queue:restart tells them to exit gracefully; Symfony Messenger workers need php bin/console messenger:stop-workers after the new code is on disk and the cache is warmed. A process manager then starts them again.
5. Keep the CLI and the web on the same PHP. Cron entries, workers and Composer run the CLI binary; call the versioned binary (php8.4) explicitly on servers with more than one PHP installed.

Pitfalls

• Upgrading the framework and PHP in one step, which makes failures hard to attribute.
• Committing a composer.lock resolved on a newer local PHP than production.
• Forgetting worker processes, which keep running old code and the old PHP until restarted.
• Treating a framework's support end as optional. After it, security fixes for that line stop arriving, even if the application still runs.

What you should do

1. List each application's framework version and the PHP version it runs on, CLI and web.
2. Move Laravel 11 and older, and any app on PHP 8.1 or older, onto supported versions as a priority.
3. Plan Laravel 12 applications onto PHP 8.3 or 8.4 before 31 December 2026 and onto Laravel 13 before 24 February 2027.
4. For Symfony, prefer the 7.4 LTS line unless you can follow every six-month minor release; Symfony 8 requires PHP 8.4.
5. Add composer check-platform-reqs and a worker restart to every deployment.

Sources

• laravel.com/docs/13.x/releases
• laravel.com/docs/12.x/releases
• laravel.com/docs/13.x/upgrade
• laravel.com/docs/13.x/queues
• symfony.com/releases
• symfony.com/releases.json
• symfony.com/releases/6.4.json
• symfony.com/releases/7.4.json
• symfony.com/releases/8.0.json
• symfony.com/releases/8.1.json
• symfony.com/releases/8.2.json
• symfony.com/doc/current/messenger.html
• getcomposer.org/doc/03-cli.md#check-platform-reqs
• getcomposer.org/doc/03-cli.md#prohibits-why-not
• getcomposer.org/doc/06-config.md#platform
• php.net/supported-versions.php
• php.net/eol.php