FrankenPHP: Der neue Application Server, der PHP-Deployment vereinfacht

Wer eine PHP-Anwendung betreibt, kennt das klassische Setup: ein Webserver wie Nginx oder Apache nimmt Anfragen entgegen und reicht sie über FastCGI an PHP-FPM weiter, das die eigentliche PHP-Ausführung übernimmt. Zwei getrennte Prozesse, die über eine Prozessgrenze hinweg kommunizieren müssen – mit entsprechendem Overhead bei jeder einzelnen Anfrage. FrankenPHP bricht mit diesem Modell und verbindet Webserver und PHP-Interpreter in einem einzigen Prozess. Was zunächst nach einem technischen Detail klingt, hat spürbare Auswirkungen auf Performance, Betriebskosten und Deployment-Aufwand.

Was FrankenPHP anders macht

FrankenPHP ist ein moderner Application Server für PHP, entwickelt von Kévin Dunglas – Gründer der französischen Entwicklerkooperative Les-Tilleuls.coop, Symfony-Core-Team-Mitglied und Schöpfer von API Platform. Technisch baut FrankenPHP auf Caddy auf, dem in Go geschriebenen Webserver, und integriert den PHP-Interpreter direkt in diesen Prozess. Statt PHP-FPM als separaten Prozess anzusprechen, läuft die PHP-Ausführung im selben Prozess wie der Webserver selbst – die Kommunikation zwischen Webserver und PHP-Engine über eine Prozessgrenze entfällt komplett.

Der Effekt lässt sich messen: In einem von Dunglas veröffentlichten Benchmark benötigte eine einfache Symfony-Anfrage mit FrankenPHP im Schnitt 2,53 Millisekunden, mit klassischem PHP-FPM waren es 9,45 Millisekunden. In der Praxis hängt der tatsächliche Gewinn stark von der jeweiligen Anwendung ab, doch die Kombination aus Caddy und PHP bringt eine ganze Reihe von Vorteilen praktisch automatisch mit: automatisches HTTPS über Let’s Encrypt oder ZeroSSL, HTTP/2- und HTTP/3-Unterstützung sowie strukturiertes Logging und Prometheus-Metriken direkt im Server integriert.

Worker Mode: die eigentliche Stärke

Der größte Performance-Hebel von FrankenPHP ist der sogenannte Worker Mode. Klassisches PHP arbeitet nach dem Shared-Nothing-Prinzip: Bei jeder Anfrage wird die Anwendung komplett neu gebootet – Autoloading, Dependency Injection Container, Routing-Tabellen, alles wird erneut aufgebaut und danach wieder verworfen. Im Worker Mode bleibt die Anwendung dagegen dauerhaft im Speicher geladen. Nur der eigentliche Request-Response-Zyklus läuft für jede Anfrage neu ab, der teure Bootstrap-Vorgang entfällt.

Die Aktivierung ist unkompliziert:

bash

docker run \
  -e FRANKENPHP_CONFIG="worker ./public/index.php" \
  -v $PWD:/app \
  -p 80:80 -p 443:443 -p 443:443/udp \
  dunglas/frankenphp

Für Anwendungen, deren Bootstrap-Prozess vergleichsweise aufwendig ist – bei komplexen Symfony- oder Laravel-Projekten keine Seltenheit – macht sich das deutlich bemerkbar. Der E-Commerce-Anbieter Sylius hat den Effekt für seine Plattform untersucht: Der Wechsel in den Worker Mode reduzierte die Antwortzeiten um 80 Prozent und senkte die Anzahl der benötigten Server um mehr als das Sechsfache, um dieselbe Nutzerlast zu bedienen.

Beide großen PHP-Frameworks haben den Worker Mode bereits fest integriert: Laravel über den Laravel Octane-Ansatz und Symfony über das Symfony Runtime Component, sodass sich bestehende Anwendungen ohne größere Architekturänderungen umstellen lassen.

Deployment: ein Binary statt vieler bewegter Teile

Ein weiterer praktischer Vorteil betrifft das Deployment selbst. FrankenPHP lässt sich als vollständig statisch kompiliertes Binary herunterladen, das FrankenPHP selbst, den Webserver Caddy, die PHP-Engine sowie die gängigsten PHP-Extensions und deren Abhängigkeiten enthält – ganz ohne separate Installation von Nginx, PHP-FPM und den benötigten PHP-Modulen. Alternativ stehen offizielle Docker-Images bereit, außerdem vorgefertigte Container für verbreitete PHP-Anwendungen wie WordPress, Symfony, Drupal, Joomla und Laravel.

Auch der Betrieb selbst wurde in den letzten Versionen deutlich komfortabler: Seit Version 1.5 skaliert FrankenPHP die Anzahl der PHP-Threads automatisch zur Laufzeit, statt eine feste Thread-Zahl vorzugeben – über die Option max_threads lässt sich dabei eine Obergrenze definieren, ähnlich dem pm.max_children bei klassischem PHP-FPM. Ein max_wait_time sorgt zusätzlich dafür, dass sich der Server bei Lastspitzen schneller erholt, statt Anfragen unbegrenzt in einer Warteschlange aufzustauen.

Offizielle Unterstützung durch die PHP Foundation

Am 15. Mai 2025 wurde FrankenPHP offiziell von der PHP Foundation unterstützt – ein deutliches Signal dafür, dass es sich nicht mehr um ein experimentelles Nebenprojekt handelt, sondern um eine ernst genommene Laufzeitumgebung für PHP-Anwendungen. Nur wenige Wochen später, am 8. Juni 2025, wechselte der Quellcode dann in die offizielle PHP-Organisation auf GitHub – exakt an dem Tag, an dem PHP seinen 30. Geburtstag feierte: Am 8. Juni 1995 hatte Rasmus Lerdorf die erste Version der Sprache veröffentlicht. Ein symbolträchtiger Zeitpunkt für einen Schritt, den die PHP Foundation selbst als ersten Meilenstein einer tieferen Integration von FrankenPHP in das PHP-Ökosystem bezeichnet. Hosting-Anbieter wie Upsun, Laravel Cloud und Clever Cloud unterstützen FrankenPHP inzwischen nativ, und das Projekt zählt mittlerweile mehrere tausend GitHub-Stars und über 100 Contributors – ein aktives, wachsendes Ökosystem.

Neben Performance und vereinfachtem Deployment nennt die PHP Foundation ein weiteres, im PHP-Ökosystem einzigartiges Merkmal von FrankenPHP: native Unterstützung für das Echtzeit-Protokoll Mercure. Damit lassen sich Echtzeit-Funktionen wie Live-Benachrichtigungen oder automatische UI-Updates direkt aus einer FrankenPHP-Anwendung heraus umsetzen, ohne zusätzliche Infrastruktur wie einen separaten WebSocket-Server aufzusetzen. Darüber hinaus lassen sich PHP-Anwendungen mit FrankenPHP um Go-, C- und C++-Code erweitern – und umgekehrt kann jede in Go geschriebene Anwendung, etwa ein Server oder Proxy, PHP-Unterstützung erhalten.

Wichtig für die Praxis: FrankenPHP tritt nicht in Konkurrenz zu PHP-FPM im Sinne eines Ersatzes, der PHP-FPM verdrängen muss. PHP-FPM bleibt vollständig unterstützt und ist für viele bestehende Setups weiterhin eine solide Wahl. FrankenPHP ist vor allem dort interessant, wo Performance unter Last, einfacheres Deployment oder die Worker-Mode-Vorteile für komplexe Framework-Anwendungen den Ausschlag geben.

Unsere Einschätzung

FrankenPHP zeigt exemplarisch, wohin sich das PHP-Ökosystem gerade entwickelt: weg von historisch gewachsenen, mehrteiligen Server-Setups, hin zu schlankeren, in sich geschlossenen Application Servern, die Performance und Betriebsaufwand gleichzeitig verbessern. Für neue Projekte lohnt sich ein Blick auf FrankenPHP von Anfang an, insbesondere bei Symfony- oder Laravel-Anwendungen mit spürbarem Bootstrap-Overhead. Für bestehende Anwendungen ist der Umstieg in der Regel unkompliziert möglich, sollte aber wie jede Änderung an der Infrastruktur zunächst in einer Staging-Umgebung getestet werden.

Wenn Sie prüfen möchten, ob sich FrankenPHP für Ihre PHP-Anwendung lohnt – von der Performance-Analyse bis zur konkreten Migration – sprechen Sie uns gerne an.