You Know Laravel. Do You Know How It Runs?
I spoke at the Laravel Denmark Copenhagen Meetup about what happens when your Laravel app actually runs. From php artisan serve to php-fpm, Octane, and FrankenPHP - the runtime matters more than most developers think.
Last week I spoke at the Laravel Copenhagen Meetup at Adapt Agency. Peter Suhm from Tailwind Labs also presented, demoing MCP servers in Laravel applications. My talk was about something most Laravel developers take for granted: how their application actually runs.
The runtime gap
Laravel developers know their framework deeply. Routes, middleware, Eloquent, queues, events. But ask how a request gets from the browser to their controller, and the answer often stops at "Nginx, I think?" The gap between application code and runtime execution is where performance, reliability, and observability problems live.
What I covered
The talk walked through four ways to run a Laravel application, each with different trade-offs:
php artisan serve is what most developers start with. It's single-threaded, synchronous, and not suitable for production. But it's useful to understand because it shows the simplest possible request lifecycle.
php-fpm + Nginx is the traditional production setup. A process manager (php-fpm) maintains a pool of worker processes, and Nginx proxies requests to them via FastCGI. This is battle-tested and well-understood, but the process management is often misconfigured. Most teams run with default pool settings and never look at metrics.
Laravel Octane keeps the application in memory between requests, eliminating the bootstrap cost on every request. The performance gains are real, but it changes how you think about state, memory leaks, and application lifecycle. Not every application is a good fit.
FrankenPHP embeds PHP directly into a Go-based web server (Caddy). It supports worker mode similar to Octane, plus early hints and real-time capabilities. It's newer, but the architecture is compelling.
Why this matters for Cbox
This talk connects directly to what I'm building with Cbox Init and FPM Exporter. Init's a process supervisor designed specifically for PHP containers. FPM Exporter exposes php-fpm metrics that most monitoring setups miss entirely. Both tools exist because the runtime layer is where PHP teams have the least visibility and the most problems.
Understanding how your application runs isn't optional if you care about production reliability. The runtime isn't someone else's problem. It's yours.
What is next
I've more talks planned on PHP infrastructure topics. If you run a meetup and want a speaker who will talk about the parts of PHP deployment that nobody wants to think about, get in touch.