Symfony LTS Versions: Which Version for Which Project, and How Long Is It Safe?
Someone on your team opens composer.json, sees "symfony/framework-bundle": "6.4.*", and asks the obvious question: is that still fine? The answer depends on the date, and the date moves. Symfony LTS versions are supported for four years, regular versions for sixteen months, and the calendar for both is published in advance. Most teams still get caught out, usually because nobody wrote the end-of-life date next to the version number when the project started.
This post is the version overview I send to clients before we talk about an upgrade. It covers how the Symfony release model works, what is maintained today (September 2026), which PHP version each Symfony release needs, and a plain decision rule for new projects, running products and older codebases.
All dates below come from the official Symfony releases page. Check it before you make a decision that depends on a month.
How the Symfony release model works
Symfony ships a new minor version every six months, in May and November. Every two years the November release is a new major version. The rules for how long each release is maintained are fixed, which is what makes planning possible:
- Regular releases (x.0, x.1, x.2, x.3) get 8 months of bug fixes and then 8 months of security fixes. Total lifetime: 16 months.
- LTS releases (always the x.4 release of a major) get 3 years of bug fixes and then 1 year of security fixes. Total lifetime: 4 years.
Since Symfony 2.7, "long-term support" has meant the same thing every time: the last minor of a major line freezes and stays patched for four years. Symfony 5.4, 6.4 and 7.4 are the three recent examples. Symfony 8.4, due in November 2027, will be the next one.
Two other properties of the model matter for upgrades. The x.4 LTS and the following x+1.0 release ship at the same time with the same features; 8.0 is 7.4 with the deprecated code removed. And Symfony never breaks compatibility inside a major line, so if your 7.4 application runs without deprecation warnings, the jump to 8.x is mostly a version bump.
The current Symfony support matrix (September 2026)
| Version | Type | Released | Bug fixes until | Security fixes until | Minimum PHP | Status today |
|---|---|---|---|---|---|---|
| 5.4 | LTS | Nov 2021 | Nov 2024 | Feb 2029 | 7.2.5 | Security fixes only |
| 6.4 | LTS | Nov 2023 | Nov 2026 | Nov 2027 | 8.1 | Maintained |
| 7.0 to 7.3 | Regular | Nov 2023 to May 2025 | ended | ended (7.3: Jan 2026) | 8.2 | Unmaintained |
| 7.4 | LTS | Nov 2025 | Nov 2028 | Nov 2029 | 8.2 | Maintained (current LTS) |
| 8.0 | Regular | Nov 2025 | Jul 2026 | Jul 2026 | 8.4 | Unmaintained |
| 8.1 | Regular | May 2026 | Jan 2027 | Jan 2027 | 8.4 | Maintained (current stable) |
| 8.2 | Regular | Nov 2026 (planned) | Jul 2027 | Jul 2027 | 8.4 | Under development |
| 8.4 | LTS | Nov 2027 (planned) | Nov 2030 | Nov 2031 | 8.4 or higher | Not released |
Three things in this table surprise people.
Symfony 5.4 gets security fixes until February 2029, not November 2025. The original schedule ended in November 2025; the security window was extended, and the releases page now lists February 2029. That is a security-only window. Bug fixes for 5.4 stopped in November 2024, so anything that is not a security issue stays broken. It also does nothing about the fact that 5.4 was built for PHP 7.2 and the PHP versions people actually run it on are themselves out of support.
Symfony 7.0, 7.1, 7.2 and 7.3 are all dead. The regular releases are short lived by design. 7.3 stopped receiving security fixes in January 2026. If you are on any 7.x version below 7.4, you are on unmaintained code, and the fix is a minor bump to 7.4 with no breaking changes.
Symfony 8.0 is already unmaintained. It was released in November 2025 alongside 7.4 and reached end of life in July 2026. Teams that started a project on 8.0 need to be on 8.1 by now, and on 8.2 by early 2027.
Which PHP version each Symfony version needs
Symfony's PHP floor changes with each major, and occasionally with a minor (6.1 raised it from 8.0 to 8.1 inside the 6.x line). The current requirements:
| Symfony line | Minimum PHP | Highest sensible PHP |
|---|---|---|
| 5.4 | 7.2.5 | 8.3 (8.4 runs with deprecation noise in older dependencies) |
| 6.4 | 8.1 | 8.4 |
| 7.x | 8.2 | 8.5 |
| 8.x | 8.4 | 8.5 |
The PHP side of the calendar matters just as much as the Symfony side. Since PHP 8.1, each PHP release gets two years of active support and two years of security fixes. PHP 8.1 reached the end of security support on 31 December 2025. PHP 8.2 ends in December 2026, PHP 8.3 in December 2027, PHP 8.4 in December 2028.
That produces an awkward combination for Symfony 6.4. The framework is maintained until November 2027, but its minimum PHP version has been unsupported since the start of 2026. A 6.4 application on PHP 8.1 is only half maintained. Move it to PHP 8.3 or 8.4 (6.4 supports both) and you are fine again. In practice the PHP upgrade is usually the harder part, and we have a separate guide on upgrading PHP 7.4 to 8.3 without breaking production.
The same logic applies to Symfony 7.4 on PHP 8.2 in about three months. Symfony 7.4 lives until 2029, PHP 8.2 ends this December. Plan the PHP 8.3 or 8.4 bump now rather than in January.
Which Symfony version for which project
The decision has fewer variables than the table suggests. What matters is how often the team is willing to run a framework upgrade and whether the application has to sit still for long stretches.
New projects: Symfony 8.1 on PHP 8.4 (or 7.4 if you cannot upgrade twice a year)
For a project starting this month, the default recommendation is Symfony 8.1 on PHP 8.4 or 8.5. 8.1 is the current stable release and contains every feature that exists. The cost is the upgrade cadence: you will bump to 8.2 in November, 8.3 in May 2027 and 8.4 LTS in November 2027. Each of those bumps is a minor upgrade without breaking changes, and on a young codebase with good test coverage it takes an afternoon.
If the team cannot commit to that cadence (an agency handing the project to a client without developers, or an internal tool that gets touched twice a year), start on Symfony 7.4 instead. It is maintained until November 2029, it runs on PHP 8.2 through 8.5, and it has the same feature set as 8.0. You give up the features added in 8.1 and later. For most business applications that is a small price.
The one option I would not pick for a new project is 6.4. It is maintained, but you would be starting on a version with fourteen months of bug fixes left and a minimum PHP version that is already out of support.
Running products: stay on LTS, upgrade LTS to LTS
For a product in production with paying customers, the boring answer is the right one: run the current LTS and move to the next one during its first year. Concretely, that means 7.4 today and a move to 8.4 sometime in 2028.
The reason to move within the first year of the new LTS rather than at the last minute is overlap. Symfony 7.4 receives bug fixes until November 2028, and 8.4 ships in November 2027. That gives you a twelve-month window in which both versions get bug fixes, so a regression found during the upgrade can be fixed on either side. Teams that wait until 7.4 is in its security-only year lose that safety net.
If you are on 6.4 right now, the same window is open until November 2026 for the move to 7.4. After that, 6.4 is security-only for a year and then gone. The 6.4 to 7.4 upgrade is a major version jump, but the deprecation model makes it predictable: fix every deprecation reported by the 6.4 profiler and test suite, then bump the constraints. The Symfony 7 upgrade guide walks through the changes that trip teams up.
Legacy applications: 5.4 is a holding pattern, not a home
Symfony 5.4 with security support until February 2029 sounds like permission to stay put. It is not. Three reasons:
- Bug fixes ended in November 2024. Any non-security defect in the framework stays as it is.
- The bundle ecosystem has moved on. New bundle releases increasingly require 6.4 or 7.x, so you end up pinned to old bundle versions with their own unpatched issues.
- The PHP versions 5.4 was designed for (7.2 to 8.1) are all out of support. Running 5.4 on PHP 8.3 works but exposes you to deprecation noise and edge cases the framework was never tested against.
Treat the extended security window as time to plan a proper migration, not as a reason to skip one. The realistic path is 5.4 to 6.4 (PHP 8.1 or higher, ideally 8.3), then 6.4 to 7.4 once the first step is stable. Rector automates a large share of the mechanical changes; we described the workflow in Rector for legacy PHP. For applications on Symfony 4.4 or older, which have had no security fixes since November 2023, the Symfony 5 to 7 migration without a code freeze post covers how to do it while the product keeps shipping features.
When an LTS-to-LTS upgrade stops being optional
An upgrade stops being optional when one of these is true:
- The version you run has stopped receiving security fixes, or will within the next six months. For 6.4 that date is November 2027; for 7.4 it is November 2029.
- The PHP version you run has stopped receiving security fixes. That is already true for PHP 8.1 and will be true for PHP 8.2 in December 2026.
- A bundle or library you depend on has dropped support for your Symfony version and you need a fix or feature from a newer release.
- A security audit, a customer questionnaire or an insurer asks for the support status of your stack. "Unmaintained framework version" is a finding you cannot argue with.
If none of those apply, you are allowed to wait. LTS exists so that teams can choose a version once and leave it alone for a long time. Just write the end-of-life date somewhere visible, ideally in composer.json as a comment or in the project README, so the next person who asks "is that still fine?" gets an answer without opening this article.
Roadmap: what comes next
The published schedule after 8.1 is 8.2 in November 2026 (maintained until July 2027), 8.3 in May 2027, and 8.4 LTS in November 2027 with bug fixes until November 2030 and security fixes until November 2031. Symfony 9.0 is expected in November 2027 alongside 8.4, following the pattern set by 7.4 and 8.0. All 8.x releases require PHP 8.4; 8.4 LTS may raise that floor, since minor releases have raised the PHP requirement before.
For planning purposes, the two dates worth putting in a calendar today are November 2026 (end of 6.4 bug fixes, start of the PHP 8.2 end-of-life countdown) and November 2027 (release of 8.4 LTS, end of 6.4 security fixes).
How we help with Symfony version decisions
At Wolf-Tech we run Symfony version audits for teams that inherited an application and do not know how exposed they are, and we plan and execute upgrades for teams that do know and want it done without a feature freeze. The audit produces a one-page support status for the framework, PHP and every bundle, plus an estimate of the upgrade effort. Where the codebase has drifted far from current Symfony practice, that audit usually turns into a legacy code optimization engagement; where the question is which version to standardise on across several products, it belongs under tech stack strategy. A code quality review before the upgrade is often the cheapest way to find out how much of the deprecation backlog is real.
If you want a second opinion on which Symfony version your project should be on, or an estimate for getting there, write to hello@wolf-tech.io or have a look at wolf-tech.io.
FAQ
Which Symfony version is LTS right now? Symfony 7.4, released in November 2025, is the current long-term support version. It receives bug fixes until November 2028 and security fixes until November 2029. Symfony 6.4 is also still maintained (bug fixes until November 2026, security fixes until November 2027).
Is Symfony 6.4 still supported? Yes, until November 2027 for security fixes. Bug fixes stop in November 2026. Its minimum PHP version, 8.1, has been out of support since the end of 2025, so run 6.4 on PHP 8.3 or 8.4.
Is Symfony 5.4 still supported? Only for security fixes, until February 2029. Bug fixes ended in November 2024. Plan a migration to 6.4 and then 7.4.
What PHP version does Symfony 7.4 require? PHP 8.2.0 or higher. It also runs on PHP 8.3, 8.4 and 8.5. Symfony 8.x requires PHP 8.4.
When is the next Symfony LTS? Symfony 8.4, planned for November 2027, with support until November 2031.