Symfony LTS-Versionen: Welche Version für welches Projekt, und wie lange ist sie sicher?

Jemand im Team öffnet composer.json, sieht "symfony/framework-bundle": "6.4.*" und stellt die naheliegende Frage: ist das noch okay? Die Antwort hängt vom Datum ab, und das Datum bewegt sich. Symfony-LTS-Versionen werden vier Jahre lang gepflegt, reguläre Versionen sechzehn Monate, und der Kalender für beide ist im Voraus veröffentlicht. Die meisten Teams werden trotzdem überrascht, meist weil niemand das End-of-Life-Datum neben die Versionsnummer geschrieben hat, als das Projekt startete.

Dieser Beitrag ist der Versionsüberblick, den ich Kunden schicke, bevor wir über ein Upgrade sprechen. Er behandelt, wie das Symfony-Release-Modell funktioniert, was heute (September 2026) gepflegt wird, welche PHP-Version jede Symfony-Version braucht, und eine einfache Entscheidungsregel für neue Projekte, laufende Produkte und ältere Codebasen.

Alle Daten unten stammen von der offiziellen Symfony-Releases-Seite. Prüfe sie, bevor du eine Entscheidung triffst, die von einem Monat abhängt.

---

Wie das Symfony-Release-Modell funktioniert

Symfony veröffentlicht alle sechs Monate eine neue Minor-Version, im Mai und im November. Alle zwei Jahre ist das November-Release eine neue Major-Version. Die Regeln, wie lange jedes Release gepflegt wird, sind fest, was Planung überhaupt erst möglich macht:

• Reguläre Releases (x.0, x.1, x.2, x.3) bekommen 8 Monate Bugfixes und danach 8 Monate Sicherheitsfixes. Gesamtlebensdauer: 16 Monate.
• LTS-Releases (immer die x.4-Version einer Major-Linie) bekommen 3 Jahre Bugfixes und danach 1 Jahr Sicherheitsfixes. Gesamtlebensdauer: 4 Jahre.

Seit Symfony 2.7 bedeutet "Long-Term Support" jedes Mal dasselbe: Die letzte Minor-Version einer Major-Linie wird eingefroren und vier Jahre lang gepatcht. Symfony 5.4, 6.4 und 7.4 sind die drei aktuellen Beispiele. Symfony 8.4, fällig im November 2027, wird das nächste sein.

Zwei weitere Eigenschaften des Modells sind für Upgrades wichtig. Die x.4-LTS und das folgende x+1.0-Release erscheinen gleichzeitig mit denselben Features; 8.0 ist 7.4 mit entferntem, veraltetem Code. Und Symfony bricht innerhalb einer Major-Linie nie die Kompatibilität, sodass der Sprung zu 8.x meist nur eine Versionsanhebung ist, wenn deine 7.4-Anwendung ohne Deprecation-Warnungen läuft.

Die aktuelle Symfony-Support-Matrix (September 2026)

Version	Typ	Veröffentlicht	Bugfixes bis	Sicherheitsfixes bis	Minimales PHP	Status heute
5.4	LTS	Nov 2021	Nov 2024	Feb 2029	7.2.5	Nur Sicherheitsfixes
6.4	LTS	Nov 2023	Nov 2026	Nov 2027	8.1	Gepflegt
7.0 bis 7.3	Regulär	Nov 2023 bis Mai 2025	beendet	beendet (7.3: Jan 2026)	8.2	Nicht gepflegt
7.4	LTS	Nov 2025	Nov 2028	Nov 2029	8.2	Gepflegt (aktuelle LTS)
8.0	Regulär	Nov 2025	Jul 2026	Jul 2026	8.4	Nicht gepflegt
8.1	Regulär	Mai 2026	Jan 2027	Jan 2027	8.4	Gepflegt (aktuell stabil)
8.2	Regulär	Nov 2026 (geplant)	Jul 2027	Jul 2027	8.4	In Entwicklung
8.4	LTS	Nov 2027 (geplant)	Nov 2030	Nov 2031	8.4 oder höher	Nicht veröffentlicht

Drei Dinge in dieser Tabelle überraschen die Leute.

Symfony 5.4 bekommt Sicherheitsfixes bis Februar 2029, nicht bis November 2025. Der ursprüngliche Zeitplan endete im November 2025; das Sicherheitsfenster wurde verlängert, und die Releases-Seite listet jetzt Februar 2029. Das ist ein reines Sicherheitsfenster. Bugfixes für 5.4 endeten im November 2024, also bleibt alles, was kein Sicherheitsproblem ist, kaputt. Es ändert auch nichts daran, dass 5.4 für PHP 7.2 gebaut wurde und die PHP-Versionen, auf denen es tatsächlich läuft, selbst nicht mehr unterstützt werden.

Symfony 7.0, 7.1, 7.2 und 7.3 sind alle tot. Die regulären Releases sind bewusst kurzlebig. 7.3 erhielt ab Januar 2026 keine Sicherheitsfixes mehr. Wenn du auf einer beliebigen 7.x-Version unter 7.4 bist, läufst du auf nicht gepflegtem Code, und die Lösung ist ein Minor-Sprung auf 7.4 ohne Breaking Changes.

Symfony 8.0 ist bereits nicht mehr gepflegt. Es erschien im November 2025 zusammen mit 7.4 und erreichte im Juli 2026 das End-of-Life. Teams, die ein Projekt mit 8.0 begonnen haben, müssen jetzt auf 8.1 sein und bis Anfang 2027 auf 8.2.

Welche PHP-Version jede Symfony-Version braucht

Symfonys PHP-Untergrenze ändert sich mit jeder Major-Version und gelegentlich mit einer Minor-Version (6.1 hob sie innerhalb der 6.x-Linie von 8.0 auf 8.1 an). Die aktuellen Anforderungen:

Symfony-Linie	Minimales PHP	Höchstes sinnvolles PHP
5.4	7.2.5	8.3 (8.4 läuft mit Deprecation-Rauschen in älteren Abhängigkeiten)
6.4	8.1	8.4
7.x	8.2	8.5
8.x	8.4	8.5

Die PHP-Seite des Kalenders zählt genauso stark wie die Symfony-Seite. Seit PHP 8.1 bekommt jedes PHP-Release zwei Jahre aktiven Support und zwei Jahre Sicherheitsfixes. PHP 8.1 erreichte am 31. Dezember 2025 das Ende des Sicherheitssupports. PHP 8.2 endet im Dezember 2026, PHP 8.3 im Dezember 2027, PHP 8.4 im Dezember 2028.

Das ergibt eine unangenehme Kombination für Symfony 6.4. Das Framework wird bis November 2027 gepflegt, aber seine minimale PHP-Version ist seit Anfang 2026 nicht mehr unterstützt. Eine 6.4-Anwendung auf PHP 8.1 ist nur halb gepflegt. Bewege sie auf PHP 8.3 oder 8.4 (6.4 unterstützt beide) und alles ist wieder in Ordnung. In der Praxis ist das PHP-Upgrade meist der schwierigere Teil, und wir haben einen eigenen Leitfaden zum Upgrade von PHP 7.4 auf 8.3, ohne die Produktion zu brechen.

Dieselbe Logik gilt für Symfony 7.4 auf PHP 8.2 in etwa drei Monaten. Symfony 7.4 lebt bis 2029, PHP 8.2 endet diesen Dezember. Plane den Sprung auf PHP 8.3 oder 8.4 jetzt, nicht erst im Januar.

Welche Symfony-Version für welches Projekt

Die Entscheidung hat weniger Variablen, als die Tabelle vermuten lässt. Was zählt, ist, wie oft das Team bereit ist, ein Framework-Upgrade durchzuführen, und ob die Anwendung über längere Strecken stillstehen muss.

Neue Projekte: Symfony 8.1 auf PHP 8.4 (oder 7.4, wenn zweimal jährlich upzugraden nicht machbar ist)

Für ein Projekt, das diesen Monat startet, lautet die Standardempfehlung Symfony 8.1 auf PHP 8.4 oder 8.5. 8.1 ist das aktuelle stabile Release und enthält jedes existierende Feature. Der Preis ist der Upgrade-Rhythmus: du springst im November auf 8.2, im Mai 2027 auf 8.3 und im November 2027 auf die 8.4-LTS. Jeder dieser Sprünge ist ein Minor-Upgrade ohne Breaking Changes, und bei einer jungen Codebasis mit guter Testabdeckung dauert das einen Nachmittag.

Wenn das Team sich diesen Rhythmus nicht leisten kann (eine Agentur, die das Projekt an einen Kunden ohne eigene Entwickler übergibt, oder ein internes Tool, das zweimal im Jahr angefasst wird), starte stattdessen mit Symfony 7.4. Es wird bis November 2029 gepflegt, läuft auf PHP 8.2 bis 8.5 und hat denselben Funktionsumfang wie 8.0. Du verzichtest auf die Features, die in 8.1 und später hinzukamen. Für die meisten Business-Anwendungen ist das ein kleiner Preis.

Die eine Option, die ich für ein neues Projekt nicht wählen würde, ist 6.4. Sie wird gepflegt, aber du würdest mit einer Version starten, die noch vierzehn Monate Bugfixes übrig hat und eine minimale PHP-Version, die bereits nicht mehr unterstützt wird.

Laufende Produkte: bei LTS bleiben, LTS-zu-LTS upgraden

Für ein Produkt in Produktion mit zahlenden Kunden ist die langweilige Antwort die richtige: die aktuelle LTS betreiben und im ersten Jahr der nächsten wechseln. Konkret bedeutet das heute 7.4 und irgendwann 2028 ein Wechsel auf 8.4.

Der Grund, innerhalb des ersten Jahres der neuen LTS zu wechseln statt in letzter Minute, ist die Überlappung. Symfony 7.4 bekommt Bugfixes bis November 2028, und 8.4 erscheint im November 2027. Das gibt dir ein zwölfmonatiges Fenster, in dem beide Versionen Bugfixes bekommen, sodass eine während des Upgrades gefundene Regression auf beiden Seiten behoben werden kann. Teams, die warten, bis 7.4 in seinem Nur-Sicherheit-Jahr ist, verlieren dieses Sicherheitsnetz.

Wenn du gerade auf 6.4 bist, ist dasselbe Fenster bis November 2026 für den Wechsel auf 7.4 offen. Danach ist 6.4 ein Jahr lang nur-Sicherheit und dann vorbei. Das Upgrade von 6.4 auf 7.4 ist ein Major-Versionssprung, aber das Deprecation-Modell macht ihn vorhersehbar: behebe jede Deprecation, die der 6.4-Profiler und die Test-Suite melden, und hebe dann die Constraints an. Der Symfony-7-Upgrade-Leitfaden geht die Änderungen durch, die Teams stolpern lassen.

Legacy-Anwendungen: 5.4 ist eine Warteschleife, kein Zuhause

Symfony 5.4 mit Sicherheitssupport bis Februar 2029 klingt nach der Erlaubnis, einfach zu bleiben. Ist es nicht. Drei Gründe:

1. Bugfixes endeten im November 2024. Jeder Nicht-Sicherheitsfehler im Framework bleibt, wie er ist.
2. Das Bundle-Ökosystem ist weitergezogen. Neue Bundle-Releases verlangen zunehmend 6.4 oder 7.x, sodass du auf alten Bundle-Versionen mit ihren eigenen ungepatchten Problemen festsitzt.
3. Die PHP-Versionen, für die 5.4 entworfen wurde (7.2 bis 8.1), werden alle nicht mehr unterstützt. 5.4 auf PHP 8.3 zu betreiben funktioniert, setzt dich aber Deprecation-Rauschen und Grenzfällen aus, gegen die das Framework nie getestet wurde.

Behandle das verlängerte Sicherheitsfenster als Zeit, eine richtige Migration zu planen, nicht als Grund, sie zu überspringen. Der realistische Weg ist 5.4 zu 6.4 (PHP 8.1 oder höher, idealerweise 8.3), dann 6.4 zu 7.4, sobald der erste Schritt stabil ist. Rector automatisiert einen großen Teil der mechanischen Änderungen; wir haben den Workflow in Rector für Legacy-PHP beschrieben. Für Anwendungen auf Symfony 4.4 oder älter, die seit November 2023 keine Sicherheitsfixes mehr erhalten haben, deckt der Beitrag Symfony-5-zu-7-Migration ohne Code-Freeze ab, wie man das macht, während das Produkt weiter Features liefert.

Wann ein LTS-zu-LTS-Upgrade nicht mehr optional ist

Ein Upgrade hört auf, optional zu sein, wenn eines davon zutrifft:

• Die Version, die du betreibst, hat aufgehört, Sicherheitsfixes zu bekommen, oder wird das innerhalb der nächsten sechs Monate. Für 6.4 ist dieses Datum November 2027; für 7.4 ist es November 2029.
• Die PHP-Version, die du betreibst, hat aufgehört, Sicherheitsfixes zu bekommen. Das gilt bereits für PHP 8.1 und wird im Dezember 2026 für PHP 8.2 gelten.
• Ein Bundle oder eine Library, von der du abhängst, hat den Support für deine Symfony-Version fallen gelassen und du brauchst einen Fix oder ein Feature aus einem neueren Release.
• Ein Sicherheitsaudit, ein Kundenfragebogen oder ein Versicherer fragt nach dem Support-Status deines Stacks. "Nicht gepflegte Framework-Version" ist ein Befund, gegen den du nicht argumentieren kannst.

Wenn nichts davon zutrifft, darfst du warten. LTS existiert, damit Teams einmal eine Version wählen und sie lange in Ruhe lassen können. Schreib nur das End-of-Life-Datum irgendwo sichtbar auf, idealerweise als Kommentar in composer.json oder im Projekt-README, damit die nächste Person, die fragt "ist das noch okay?", eine Antwort bekommt, ohne diesen Artikel zu öffnen.

Roadmap: was als Nächstes kommt

Der veröffentlichte Zeitplan nach 8.1 sieht 8.2 im November 2026 vor (gepflegt bis Juli 2027), 8.3 im Mai 2027, und die 8.4-LTS im November 2027 mit Bugfixes bis November 2030 und Sicherheitsfixes bis November 2031. Symfony 9.0 wird für November 2027 zusammen mit 8.4 erwartet, dem Muster von 7.4 und 8.0 folgend. Alle 8.x-Releases brauchen PHP 8.4; die 8.4-LTS könnte diese Untergrenze anheben, da Minor-Releases die PHP-Anforderung schon früher erhöht haben.

Für die Planung lohnen sich heute zwei Termine im Kalender: November 2026 (Ende der 6.4-Bugfixes, Start des Countdowns für das End-of-Life von PHP 8.2) und November 2027 (Release der 8.4-LTS, Ende der 6.4-Sicherheitsfixes).

Wie wir bei Symfony-Versionsentscheidungen helfen

Bei Wolf-Tech führen wir Symfony-Versionsaudits für Teams durch, die eine Anwendung geerbt haben und nicht wissen, wie exponiert sie sind, und wir planen und führen Upgrades für Teams durch, die es wissen und es ohne Feature-Freeze erledigt haben wollen. Das Audit liefert einen einseitigen Support-Status für das Framework, PHP und jedes Bundle, plus eine Schätzung des Upgrade-Aufwands. Wo die Codebasis weit von der aktuellen Symfony-Praxis abgedriftet ist, wird aus diesem Audit meist ein Legacy-Code-Optimierungs-Projekt; wo die Frage ist, auf welche Version man über mehrere Produkte hinweg vereinheitlichen soll, gehört das zur Tech-Stack-Strategie. Ein Code-Quality-Review vor dem Upgrade ist oft der günstigste Weg, herauszufinden, wie groß der reale Deprecation-Rückstau ist.

Wenn du eine zweite Meinung dazu willst, welche Symfony-Version dein Projekt haben sollte, oder eine Schätzung, wie du dorthin kommst, schreib an hello@wolf-tech.io oder schau bei wolf-tech.io vorbei.

FAQ

Welche Symfony-Version ist gerade LTS? Symfony 7.4, veröffentlicht im November 2025, ist die aktuelle Long-Term-Support-Version. Es bekommt Bugfixes bis November 2028 und Sicherheitsfixes bis November 2029. Symfony 6.4 wird ebenfalls noch gepflegt (Bugfixes bis November 2026, Sicherheitsfixes bis November 2027).

Wird Symfony 6.4 noch unterstützt? Ja, bis November 2027 für Sicherheitsfixes. Bugfixes enden im November 2026. Seine minimale PHP-Version, 8.1, wird seit Ende 2025 nicht mehr unterstützt, also betreibe 6.4 auf PHP 8.3 oder 8.4.

Wird Symfony 5.4 noch unterstützt? Nur für Sicherheitsfixes, bis Februar 2029. Bugfixes endeten im November 2024. Plane eine Migration zu 6.4 und dann 7.4.

Welche PHP-Version braucht Symfony 7.4? PHP 8.2.0 oder höher. Es läuft auch auf PHP 8.3, 8.4 und 8.5. Symfony 8.x braucht PHP 8.4.

Wann ist die nächste Symfony-LTS? Symfony 8.4, geplant für November 2027, mit Support bis November 2031.