Symfony 8: what changed, and should you upgrade?

By Ricardo Ribeiro · · 3 min read · PHP, Symfony

A major version that mostly tidies up

Symfony 8.0 landed in November 2025 and it is one of the less dramatic majors. It requires PHP 8.4 or higher, which is the real gate. Beyond that, most of the changes are about making the framework more predictable rather than adding features you will use on day one.

Configuration is now PHP array shapes

This is the change you notice first. XML config files and the fluent PHP builder are gone in favor of plain PHP arrays.

// config/packages/framework.php
return [
    'secret' => '%env(APP_SECRET)%',
    'session' => [
        'handler_id' => null,
        'cookie_secure' => 'auto',
    ],
];

The reason is not fashion. An array shape is something your IDE and static analysis tools can actually read, so you get autocompletion and type checking inside configuration files. After a week it is hard to argue for the old format.

Return types are enforced

Across the components, return types are no longer suggestions. If a class promises a return type, it must return that. In practice this mostly affects code that was already sloppy, and it surfaces the problem at development time instead of in production.

Performance

The container and cache layers benefit from PHP 8.4's lazy objects, and the numbers people report for warm cache performance are meaningfully better than the 7.x line. If you run an application where every millisecond of bootstrap is paid on every request, this is the argument that matters most.

Which version should you be on

Here is the honest breakdown.

  • If you are on Symfony 6.4 LTS: you are on the last LTS that does not require PHP 8.4. Plan the move, but you are not in danger yet.
  • If you are on 7.4: you are on the current LTS. Staying is a defensible decision for a year, and upgrading to 8.x is mostly configuration work.
  • If you are starting a new project: start on 8.x. There is no reason to begin on a version that will need migrating.

The upgrade in practice

Rector and the Symfony upgrade tool do most of the mechanical work, including the configuration conversion. The part they cannot do is your own code that relies on removed deprecations. Expect to spend your time there, not in the framework.

One practical tip: run the deprecation log on your current version before you upgrade. Every deprecation you fix in advance is one less surprise afterwards, and the log tells you exactly where to look.

Worth it?

If you are already on PHP 8.4, the upgrade is mostly a configuration exercise with a real performance payoff. If you are on PHP 8.2 or 8.3, the PHP upgrade is the bigger task and Symfony is the easy part afterwards. Either way, the direction is clear, and the array shape configuration is the piece that will save you time every week once it is done.

← All posts

Privacy · Cookies

Need a hand with a WordPress site that keeps breaking? See what I do and how I work.