FrankenPHP 1.4 : le mode Watcher automatise le rechargement des workers

Dans le même créneau, RoadRunner publie sa version 2026.3.0 avec un orchestrateur de processus optimisé pour réduire l'empreinte mémoire des workers PHP-FPM longue durée. Deux signaux convergents: les runtimes alternatifs de PHP ne se contentent plus de la production — ils attaquent sérieusement l'expérience de dev.

Watcher FrankenPHP: le hot-reload natif

Le principe est simple: FrankenPHP 1.4 surveille les fichiers sources et recharge automatiquement les workers sans intervention du développeur. Plus besoin de Ctrl+C, php artisan serve, ou d'un watchdog tiers comme nodemon bricolé autour d'un script shell.

Concrètement, le mode Watcher évite le cycle mort de tout dev PHP en mode worker — éditer un fichier, tuer le process, relancer, attendre le boot du framework. FrankenPHP, étant compilé en Go et gérant lui-même le cycle de vie des goroutines PHP, peut intercepter les changements de fichiers au niveau OS et déclencher un rechargement ciblé du worker concerné.

Avantage non trivial: contrairement aux solutions proxy qui rechargent tout le processus (incluant le bootstrap du framework, la connexion Doctrine, le warm-up du container DI), un rechargement natif au niveau du runtime potentiellement ne réinitialise que le code applicatif modifié. Le snippet source confirme un rechargement « plus performant » que le redémarrage manuel classique.

Ce que ça change au quotidien:

• Suppression d'un round-trip kill + relance sur chaque changement de fichier PHP
• Cycle de feedback quasi instantané sur les workers FrankenPHP (RoadRunner, Swoole, etc.)
• Moins de dépendance aux outils externes de file-watching

RoadRunner 2026.3.0: l'empreinte mémoire sous contrôle

RoadRunner de son côté optimise la gestion mémoire de son orchestrateur de processus. Le serveur d'application haute performance réduit l'empreinte mémoire des applications PHP tournant en continu via PHP-FPM.

Pourquoi c'est un enjeu: un worker PHP-FPM classique consomme entre 20 et 80 Mo selon le framework et le volume de classes autoloadées. Multiplié par 50-200 workers en production, la facture mémoire explose vite. Toute optimisation au niveau de l'orchestrateur — compaction du GC, réutilisation de pools mémoire, détection plus fine des workers idle — a un impact direct sur le coût infrastructure.

Points d'attention pour l'équipe infra:

• Benchmarker l'empreinte mémoire avant/après mise à jour sur un environnement de staging
• Comparer le RSS moyen par worker (commande ps aux | grep php ou monitoring APM)
• Vérifier la compatibilité avec les configurations pm.max_children et pm.max_requests existantes

Verdict

FrankenPHP 1.4: à adopter en dev local si vous tournez déjà sur FrankenPHP ou que vous évaluez un runtime workerisé. Le Watcher supprime un irritant quotidien, pas plus.

RoadRunner 2026.3.0: à tester en staging si vous avez des contraintes mémoire réelles. Pas de révolution, mais une optimisation ciblée qui peut se chiffrer directement en euros économisés sur le billing cloud.

Les deux outils signalent la même tendance: l'écosystème PHP mature enfin vers des runtimes qui ne se contentent pas de « faire tourner le code » mais optimisent activement le cycle complet — dev, build, run.