Laravel 14 ist noch nicht da. Stand 21. September 2026 befindet sich die nächste Major-Version in Entwicklung, und weder ein offizieller Release-Termin noch eine vollständige Feature-Liste wurden veröffentlicht.
Trotzdem lässt sich im master-Branch bereits ziemlich gut erkennen, wohin die Reise geht. Und vorweg: Laravel 14 sieht derzeit nicht nach einem Release aus, für das man bestehende Anwendungen neu planen müsste. Viele größere Neuerungen landen weiterhin direkt in Laravel 13. Für Version 14 bleiben vor allem Änderungen übrig, die bestehende Verträge, Methodensignaturen oder Verhalten ändern würden.
Wann erscheint Laravel 14?
Laravel veröffentlicht seit Jahren ungefähr eine neue Major-Version pro Jahr. Laravel 13 erschien am 17. März 2026. Wenn dieser Rhythmus beibehalten wird, ist Laravel 14 im ersten Quartal 2027 realistisch. Einen offiziellen Termin gibt es aktuell aber nicht.
Klar ist dagegen bereits eine technische Voraussetzung: Der aktuelle master-Branch verlangt PHP 8.4 oder neuer und setzt auf Symfony 8.1. Laravel 13 unterstützt offiziell noch PHP 8.3 bis 8.5.
Für neue Projekte ist das kaum ein Problem. Wer ältere Anwendungen auf Servern mit PHP 8.3 betreibt, sollte das Upgrade aber nicht erst am Tag der Laravel-14-Migration entdecken. Server, Docker-Images und CI/CD-Pipelines sollten vorher auf PHP 8.4 getestet werden.
Native Unterstützung für HTTP QUERY
Eine der sichtbareren Neuerungen ist Route::query().
Laravel 14 unterstützt damit den neuen HTTP-QUERY-Methodentyp direkt im Router:
Route::query('/products/search', function () {
// komplexe Suchanfrage
});
QUERY ist für Abfragen gedacht, die komplexer sind als ein klassischer GET-Request und deshalb einen Request-Body benötigen, dabei aber weiterhin als sichere und cachebare Abfrage behandelt werden sollen. Laravel nimmt QUERY auch in Route::any() auf.
Für die meisten normalen Websites ändert das erst einmal gar nichts. Für APIs mit komplexen Filtern, Suchsystemen oder großen strukturierten Query-Objekten ist es dagegen eine saubere Alternative zu Konstruktionen, bei denen POST nur deshalb verwendet wird, weil GET für die Anfrage unpraktisch ist.
Autorisierung wird etwas direkter
Bisher läuft eine Autorisierungsprüfung häufig über Gate oder andere Helfer. Laravel 14 ergänzt das Authorizable-Interface um authorize():
$user->authorize('update', $post);
Ist die Aktion nicht erlaubt, wird direkt eine AuthorizationException ausgelöst.
Das ist keine revolutionäre Neuerung. Es spart schlicht unnötigen Code und liest sich an Stellen gut, an denen bereits mit einem konkreten Benutzer gearbeitet wird.
Mehr Kontext bei Fehlern
Interessanter für größere Anwendungen ist die Erweiterung von report().
In Laravel 14 kann zusätzlicher Kontext direkt zusammen mit einer Exception übergeben werden:
report($e, [
'order_id' => $order->id,
'customer_id' => $customer->id,
]);
Auch der Exception Handler akzeptiert diesen Kontext entsprechend.
Das klingt klein, ist im Betrieb aber nützlich. Ein Fehler wie „Payment request failed“ hilft wenig. Derselbe Fehler zusammen mit Bestellnummer, Kunde, Provider und Prozessschritt lässt sich in Sentry, Bugsnag oder den eigenen Logs wesentlich schneller nachvollziehen.
Gerade bei automatisierter Log-Analyse und AI-gestütztem Debugging ist strukturierter Kontext deutlich wertvoller als ein langer Stacktrace ohne Geschäftsdaten.
Eloquent bekommt einige unangenehme Edge Cases los
Ein Teil von Laravel 14 besteht aus Änderungen, die weniger spektakulär aussehen, aber bestehendes Verhalten korrigieren.
chunk() und lazy() arbeiten künftig mit einem geklonten Query Builder. Der ursprüngliche Builder wird dadurch nicht mehr während der Verarbeitung verändert. Wer denselben Query anschließend erneut verwendet, bekommt damit nicht plötzlich Ergebnisse, die von einem vorherigen chunk() oder lazy() beeinflusst wurden.
Auch findOr() verhält sich bei mehreren IDs konsequenter. Wird beispielsweise nach mehreren Modellen gesucht und nicht alle existieren, kann der Callback jetzt tatsächlich ausgeführt werden, statt eine unvollständige Collection zurückzugeben.
Dazu kommen Verbesserungen rund um whereKey() und orWhereKey(). Das sind keine Features, wegen denen man ein Projekt auf Laravel 14 migriert. Es sind aber genau die kleinen Korrekturen, die später weniger Sonderfälle im eigenen Code produzieren.
Cache mit mehreren Keys funktioniert endlich eindeutig
Auch beim Cache werden einige Mehrfachoperationen klarer.
Cache::has(['products', 'categories']);
liefert in Laravel 14 nur dann true, wenn alle angegebenen Keys existieren.
Dasselbe Prinzip gilt für:
Cache::forget(['products', 'categories']);
Mehrere Keys werden tatsächlich als Gruppe verarbeitet, statt dass Entwickler dafür eigene Schleifen oder Workarounds schreiben müssen.
Wieder kein großes Feature. Aber vernünftiges Verhalten für eine API, von der man eigentlich genau das erwarten würde.
Achtung bei Queues
Eine Änderung sollte man bei einem Upgrade tatsächlich suchen und prüfen: Die Parameterreihenfolge für das Pausieren und Fortsetzen von Queues ändert sich.
Laravel 13:
Queue::pause('redis', 'emails');
Laravel 14:
Queue::pause('emails');
Queue::pause('emails', 'redis');
Der Queue-Name steht jetzt an erster Stelle. Die Connection ist optional und verwendet ohne Angabe die Standardverbindung.
Dasselbe Muster betrifft unter anderem resume(), pauseFor() und isPaused().
Das neue API ist meiner Meinung nach logisch nachvollziehbarer, aber bestehender Code muss angepasst werden. Besonders Projekte mit eigenen Queue-Management-Tools oder Deployment-Skripten sollten danach suchen.
Vorsicht bei MassPrunable und Soft Deletes
Eine weitere Änderung kann Auswirkungen auf echte Daten haben.
Bei Modellen mit MassPrunable und SoftDeletes berücksichtigt Laravel 14 standardmäßig auch bereits soft-gelöschte Datensätze. Der aktuelle Code im master-Branch aktiviert dafür intern withTrashed(). Wer dieses Verhalten nicht möchte, muss die eigene prunable()-Query entsprechend einschränken.
Das ist genau die Sorte Breaking Change, die man beim Upgrade nicht einfach mit einem composer update abhaken sollte. Wenn MassPrunable im Projekt verwendet wird, gehört die entsprechende Query auf die Upgrade-Checkliste.
Muss man sich jetzt auf Laravel 14 vorbereiten?
Für die meisten aktuellen Laravel-13-Projekte: nein.
Laravel 13 wurde erst im März 2026 veröffentlicht und erhält nach der aktuellen Support Policy Bugfixes bis Q3 2027 sowie Sicherheitsupdates bis zum 17. März 2028. Laravel 12 erhält Sicherheitsupdates noch bis zum 24. Februar 2027.
Wer heute ein neues Projekt startet, kann problemlos Laravel 13 einsetzen. Sinnvoll ist lediglich, PHP 8.4 bereits bei neuer Infrastruktur einzuplanen. Dann wird der spätere Wechsel auf Laravel 14 technisch einfacher.
Bei bestehenden Projekten würde ich vor allem vier Dinge prüfen: PHP-Version, Queue-Code, MassPrunable und eigene Erweiterungen von Laravel-Klassen oder Contracts. Genau dort entstehen bei Major-Upgrades normalerweise die echten Probleme — nicht bei den neuen Convenience-Methoden.
Laravel 14 wird vermutlich kein großer Neustart
Das ist auch nicht notwendig.
Laravel 13 hat bereits deutlich größere Änderungen gebracht: den offiziellen Laravel AI SDK, JSON:API Resources, semantische und Vector Search sowie weitere neue APIs. Laravel veröffentlicht neue Funktionen inzwischen kontinuierlich in Minor-Releases und wartet damit nicht künstlich auf die nächste Major-Version.
Laravel 14 wirkt deshalb bisher eher wie das, was eine jährliche Major-Version sein sollte: alte Kanten entfernen, APIs konsistenter machen, Abhängigkeiten aktualisieren und Änderungen einführen, die aus Gründen der Abwärtskompatibilität nicht mehr in Laravel 13 gehören.
Für Entwickler bedeutet das wahrscheinlich kein Wochenende voller Migrationen. Für Unternehmen bedeutet es noch weniger: Laravel 14 ist aktuell kein Grund, ein laufendes Projekt umzubauen oder eine geplante Entwicklung aufzuschieben.
Die relevantere Frage ist einfacher: Läuft die eigene Laravel-Anwendung auf einer aktuellen PHP-Version, gibt es automatisierte Tests und wird sie regelmäßig aktualisiert? Wenn die Antwort darauf ja lautet, dürfte auch Laravel 14 ein ziemlich unspektakuläres Upgrade werden.
