Skip to content

Symfony 7.4 LTS is the right foundation for a SaaS in 2026: here's the support math

Bug fixes until November 2028, security fixes until November 2029, and what that actually means when you're choosing the version your business will sit on.

Choosing a framework version for a SaaS is not a technical decision, it's a maintenance budget decision. You're picking how often you'll be forced to do upgrade work that customers never see. Here is the support math for Symfony in mid-2026, and why ShipAnvil sits on 7.4 LTS.

The dates that matter

From symfony.com/releases, as of June 2026:

  • Symfony 7.4 (LTS): released November 2025. Bug fixes until November 2028, security fixes until November 2029.
  • Symfony 6.4 (LTS): the previous LTS. Bug fixes end November 2026 (five months from now), security fixes end November 2027.
  • The next LTS will be Symfony 8.4, expected November 2027.

Non-LTS releases (7.3, 8.0 when it lands…) get eight months of bug fixes. They're great for agencies shipping projects that get continuous attention; they're a treadmill for a product company.

What this means for a SaaS you're starting now

Starting on 6.4 in 2026 is starting in debt. You'd have twelve months of security coverage left and an unavoidable 7.x migration on the calendar, before you've written a feature.

Starting on 7.4 buys you three quiet years. Security coverage to November 2029, and your first mandatory migration target (8.4 LTS) won't even exist until late 2027, by which point it's a deliberate, well-trodden upgrade rather than an emergency. For a small team trying to reach revenue, "no forced framework work until the business can pay for it" is exactly the guarantee you want.

There's a second-order benefit: PHP version alignment. Symfony 7.4 runs happily on PHP 8.4 (and 8.5), so you get modern engine performance (property hooks, the new JIT improvements) without sitting on a framework that will EOL under you.

"But 8.0 is newer"

Symfony's versioning makes this a non-question: 7.4 and 8.0 ship the same features: 8.0 is 7.4 minus the deprecated code paths. The upgrade path Symfony designed is: sit on 7.4, fix deprecations at your own pace (the profiler counts them for you), then the 8.x jump is mechanical. Starting a product directly on a .0 release buys you nothing except a shorter support window.

The checklist we apply (and ship)

ShipAnvil's stance, which you can steal even if you never buy it:

  1. Pin the LTS in composer.json ("symfony/framework-bundle": "7.4.*"): minor versions of dependencies move, the framework doesn't surprise you.
  2. Run the suite with deprecations visible. PHPUnit surfaces them; fixing a handful per month beats fixing three years' worth before a migration. (This is also why we keep PHPStan at level max: the 8.x upgrade will mostly be "the tools already told us".)
  3. Track the EOL dates somewhere you'll see them. November 2028 sounds far away; so did every EOL date ever.
  4. Don't fork the framework's conventions. Every "clever" deviation from standard Symfony is a tax you pay at every upgrade. Boring structure is what makes the 2029 you grateful.

If you want the foundation pre-built on exactly this reasoning (7.4 LTS, PHP 8.4+, deprecation-clean, 392 tests), that's what ShipAnvil is. Either way: check the dates yourself before committing, they're the cheapest due diligence you'll ever do.