FrankenPHP 1.11.3 Quietly Becomes the Default PHP Runtime — Here's Why Your Next Laravel Project Should Skip Nginx Entirely

If you skipped this week's PHP newsletter, you missed a release note that reads like a maintenance update and behaves like a regime change. FrankenPHP 1.11.3 shipped last week with three lines that, taken together, end Nginx + PHP-FPM as the sensible default for new Laravel and Symfony projects.

The release bumps the bundled PHP in static binaries to PHP 8.5, upgrades the underlying Caddy server to 2.11, and reverts the unreliable worker-mode INI reset that briefly broke 1.11.2. It is, in patch-note language, "stability and version bumps." In practice, it is the moment FrankenPHP becomes the runtime you would choose if you were starting fresh today.

1. Why this release is the tipping point

FrankenPHP has been technically interesting since 2023, but its adoption ceiling was always the same three concerns: "Is it stable?", "Does my framework support it?", and "Will my hosting provider run it?" In May 2026 all three concerns evaporated within a single fortnight.

Stability — 1.11.3 explicitly fixes the worker-mode regression that scared people off 1.11.2. Framework support — Symfony 8.1.0-BETA1 added FRANKENPHP_RESET_KERNEL to the Runtime component, meaning Symfony now resets the kernel between requests in worker mode without you writing glue code. Laravel Octane has supported FrankenPHP as a first-class driver for a year. Hosting — Clever Cloud's late-February image update started shipping FrankenPHP 1.11.3 as a managed runtime, and you can now pick PHP 8.5 simply by setting CC_PHP_VERSION=8.5.

Add the official PHP Foundation backing of FrankenPHP that landed earlier this year, and the political risk that previously kept conservative shops on PHP-FPM is also gone.

2. What you actually win — the numbers

The cited benchmark figure that keeps circulating is roughly 15,000 req/sec on FrankenPHP worker mode versus ~4,000 req/sec on classic PHP-FPM for the same Laravel application. Treat that as an upper bound, not a guarantee — your numbers depend heavily on framework boot cost, third-party middleware, and database round-trips. But even on a typical Laravel admin panel with Eloquent and a few packages, real-world reports cluster between 3× and 5× throughput.

The reason is structural: in worker mode, your Laravel application boots once per worker process and stays warm. No more 30–80 ms of bootstrap on every request. Static assets, HTTPS, HTTP/3, and reverse-proxy concerns are handled by Caddy 2.11 in the same binary — no separate Nginx config file, no second process to monitor, no Let's Encrypt cron.

3. PHP 8.5: small features, large refactors

PHP 8.5 lands inside FrankenPHP with three features your codebase will want this quarter: the pipe operator, clone with modifications, and a native URI extension. The pipe operator alone will let you delete a meaningful slice of collect()->map()->filter() chains in older Laravel code without losing readability. Clone-with-modifications kills a class of immutability bugs in DTO-heavy code. The native URI extension means you can stop pulling in league/uri for parsing tasks — one less dependency to audit.

4. Migration playbook — actually short for once

For an existing Laravel project, the migration is genuinely a one-afternoon job: install Octane, set the FrankenPHP server in octane.php, audit any code that holds state in static properties (this is the only common footgun in worker mode), and ship. For Symfony 8.1 projects on the new beta, set FRANKENPHP_RESET_KERNEL=1 and you get the same warm-process behavior with no kernel-state leakage.

The Docker image is officially supported. The static binary works on bare metal. Caddy handles TLS automatically. There is, for the first time, no obvious reason to introduce a separate Nginx layer in front for a typical agency client.

5. What this means for our stack going forward

For a small studio shipping client work in 2026, this changes three operational defaults. Server provisioning scripts can drop the Nginx role. The deployment pipeline gets one binary instead of two services. The on-call surface shrinks — Caddy + FrankenPHP is one process tree, not two. None of these are individually dramatic. Together they remove an entire category of "why did the site go down at 3am" tickets.

My Take

The story FrankenPHP wants you to tell is "we made PHP fast." The more honest story is "we made PHP simple again." For two decades, every serious PHP deployment has been a sandwich of Nginx, PHP-FPM, a process supervisor, and a TLS layer — four moving parts that needed to agree on timeouts, buffer sizes, and graceful reload semantics. 1.11.3 quietly collapses that sandwich into one Go binary that the Foundation now backs. Agencies who were waiting for "the inflection point" before recommending FrankenPHP to clients — that inflection point was last week, and almost nobody noticed.