Laravel 13.35.0 ist am 6. Oktober 2026 erschienen. Die Version führt eine prozentuale Speichergrenze für Queue-Worker statt eines festen Werts ein sowie eine native Methode, mit der eine geplante Aufgabe garantiert nur auf einem Server einer Flotte läuft. Daneben behebt das Release mehrere fehlerhafte Verhaltensweisen bei Eloquent-Beziehungen und der Dateiverwaltung.
Eine relative statt einer festen Speichergrenze
Bisher akzeptierte queue:work --memory nur einen absoluten Wert in Megabyte. Bei einer Worker-Flotte auf unterschiedlich dimensionierten Maschinen musste diese feste Zahl für jedes Ziel manuell angepasst oder aus Vorsicht niedrig angesetzt werden. Laravel 13.35.0 akzeptiert nun einen Prozentwert, berechnet auf Basis des insgesamt verfügbaren Speichers des Containers oder der Host-Maschine. Der Worker startet sauber neu, sobald er diese relative Schwelle überschreitet, was sowohl zu häufige Neustarts auf kleinen Instanzen als auch stille Speicherlecks auf größeren vermeidet.
Scheduler: garantierte Einzelausführung über mehrere Server
Die neue Methode Schedule::alwaysOnOneServer() gilt für alle geplanten Aufgaben einer Anwendung, ohne onOneServer() bei jedem einzelnen Eintrag wiederholen zu müssen. Für Teams, die dieselbe Codebasis auf mehreren Anwendungsservern hinter einem Load Balancer betreiben, ist dies die Einstellung, die verhindert, dass eine Cron-Aufgabe in derselben Minute zweimal ausgelöst wird. Der Befehl schedule:list --json zeigt nun pro Aufgabe ein Feld onOneServer an, wodurch sich die Konfiguration prüfen lässt, ohne den Quellcode zu lesen.
Wichtige Korrekturen: Eloquent, Uploads und Pagination
Neben den beiden Hauptneuerungen behebt die Version von der Community gemeldete Fehler: ein fehlerhaftes Verhalten der Beziehungen HasOneThrough, HasManyThrough und morphTo in bestimmten verschachtelten Eager-Loading-Szenarien sowie eine Regression bei Aktualisierungen von JSON-Pfaden in verschlüsselten Collections. Der Download von Dateien mit nicht-ASCII-Namen ist ebenfalls korrigiert, ebenso ein Fehler bei Union-Abfragen in Kombination mit Cursor-Pagination.
| Änderung | Vor 13.35.0 | Seit 13.35.0 |
|---|---|---|
| Worker-Speicher | Fester Wert in MB, pro Maschine angepasst | Prozentsatz des verfügbaren Speichers |
| Einzelausführung des Schedulers | onOneServer() pro Aufgabe wiederholt | Globales Schedule::alwaysOnOneServer() |
| Scheduler-Audit | Erforderte das Lesen des Quellcodes | schedule:list --json zeigt onOneServer |
| Dateispeicherung | copyToDisk()/moveToDisk() ohne Enum-Unterstützung | Unterstützung nativer PHP-Enums |
Bei der Speicherung akzeptieren copyToDisk() und moveToDisk() nun native PHP-Enums, und eine neue Option lazy_root_creation verhindert, dass ein Stammverzeichnis angelegt wird, bevor tatsächlich eine Datei dorthin geschrieben wird. Diese Anpassungen reihen sich ein in das Ökosystem der Kommandozeilen-Werkzeuge, die Backend-Teams täglich kombinieren, sei es Artisan oder einer der auf Mail Studio verglichenen JavaScript-Paketmanager.
Worauf zu achten ist. Die prozentuale Schwelle wird auf Basis des vom System gemeldeten Gesamtspeichers berechnet, nicht auf Basis des dem Container zugewiesenen Speichers, falls dessen cgroups nicht korrekt konfiguriert sind. Auf einer Infrastruktur, bei der Container-Limits dem Kernel nicht sichtbar gemacht werden, kann der Prozentsatz an den Speicher des physischen Hosts gekoppelt bleiben: Es lohnt sich, vor der Migration der Konfiguration zu prüfen, was free -m innerhalb des Containers ausgibt.
// Alte Einstellung: fester Wert, pro Umgebung dupliziert
// php artisan queue:work --memory=512
// Neue Einstellung: Prozentsatz des verfügbaren Speichers
php artisan queue:work --memory=75%
// Scheduler: Einzelausführung über die gesamte Flotte
use Illuminate\Support\Facades\Schedule;
Schedule::alwaysOnOneServer();
Schedule::command('reports:generate')->dailyAt('03:00');
Schedule::command('cache:prune-stale-tags')->hourly();
Mit dieser Version macht Laravel aus einer festen Speichergrenze ein maschinenrelatives Budget – ein kleines technisches Detail, das in der Produktion dennoch unnötige Worker-Neustarts verhindert.
Der Umstieg auf diese neuen Optionen bricht keine bestehende Signatur: Anwendungen, die weiterhin einen absoluten Wert an --memory übergeben, zeigen exakt dasselbe Verhalten wie zuvor. Die Migration bleibt damit vollständig optional, im Einklang mit der Kompatibilitätspolitik, wie sie bereits bei Node.js und dessen Umgang mit Standardwerten im konkurrierenden Backend-Ökosystem zu beobachten war.
Was man sich merken sollte
Laravel 13.35.0 behebt zwei konkrete operative Ärgernisse für Teams, die Queues und geplante Aufgaben in einer Multi-Server-Produktion betreiben: Der Worker-Speicher skaliert endlich mit der Maschine, und die Einzelausführung geplanter Aufgaben wird zu einer globalen Einstellung statt einer Aufgabe-für-Aufgabe-Disziplin. Die 56 zusammengeführten Pull Requests dieser Version, von 28 Mitwirkenden, sind größtenteils gezielte Korrekturen statt neuer Funktionen.
Bei den Projekten, die ich in Produktion betreue, war die feste --memory-Einstellung stets ein falscher Freund: Entweder musste sie bei jedem Instanzwechsel neu berechnet werden, oder man setzte sie aus Vorsicht niedrig an und verlor an Effizienz. Der Prozentsatz ist eine einfache Lösung für ein Problem, das die Laravel-Community seit Jahren anmerkt, und genau diese stillen Änderungen sagen mehr über die Reife eines Frameworks aus als jedes Vorzeigefeature. — Simon Janvier
Zum Weiterlesen: vollständige Release Notes zu Laravel 13.35.0 auf GitHub.
