Laravel + Cloudflare
Laravel is excellent.
I just needed a different operating model.
Most of my background is WordPress and the broader PHP ecosystem, including running and maintaining hundreds of WordPress sites. I've used Laravel where it fit and still recommend it in the right situation. This page is a practical comparison: what Laravel Cloud, Octane, and FrankenPHP improve, and why I still chose Cloudflare primitives for the projects I run today.
Chapter 1
I wasn't trying to leave the PHP ecosystem.
I spent years on WordPress and PHP operations: provisioning servers, managing updates, handling plugin and theme maintenance, and keeping production sites stable. I've also used Laravel on specific projects and respect what it does well. At some point, I noticed I was spending more time operating infrastructure than building product.
Servers to provision. Nginx configs to manage. MySQL replication to monitor. Redis for sessions. Redis for cache. Redis for queues. A scheduler that ran cron on a single machine and silently failed when that machine had a bad day. Deploys that required coordination. Zero-downtime deploys that sometimes weren't.
The framework itself was fine. The layer underneath it was the problem.
Chapter 2
What modern Laravel gets right.
Laravel Cloud
Managed PHP, done properly
Laravel Cloud is a real managed platform — EC2-backed, autoscaling, zero-config deploys. It removes the Forge/Envoyer/Vapor complexity that used to sit between you and a production PHP app. For a team that knows Laravel and wants managed hosting without re-architecting, it's a strong option.
The constraint isn't the product — it's the model. You're still scaling EC2 instances. The platform manages them, but the cost curve and cold-start characteristics are still tied to virtual machines.
Laravel Octane
Keeps the app in memory
Octane is the right response to PHP's original performance ceiling. Traditional FPM bootstraps the entire framework on every request. Octane boots once and keeps everything in memory — so the second request is dramatically faster than the first.
It runs on FrankenPHP, Swoole, or RoadRunner. Each one eliminates the per-request bootstrap cost and gives you long-running processes that behave more like Node or Go servers. Real progress.
FrankenPHP
PHP re-engineered in Go
FrankenPHP is genuinely impressive work. Built on Caddy (Go), it embeds PHP as a library, eliminating the FPM process pool entirely. Worker mode holds your app in memory. The benchmarks show 3.5× the throughput of traditional PHP-FPM.
Early builds had compatibility gaps — some SAPI functions, certain extensions — but it's been progressing quickly. For PHP, this is a meaningful step forward in the runtime model.
Where It Still Differs
If Laravel keeps improving, why did I still switch?
Because my constraint wasn't framework speed. It was operations. I wanted fewer systems to coordinate, less infrastructure ownership, and simpler global delivery.
Octane and FrankenPHP improve runtime performance a lot. Laravel Cloud improves deployment and hosting. But the baseline model is still server-oriented: instance scaling, capacity planning, and region placement. That's a valid model. It just wasn't the one I wanted to keep operating.
In other words: Laravel has improved significantly. My switch was less about language preference, and more about which operational model I wanted to run day-to-day.
Chapter 3
The architectural differences that actually matter.
Laravel / PHP model (modern setup)
Scale by increasing instance size or count. Autoscaling works, but you still plan capacity and pay for baseline uptime.
Sessions and cache usually sit in Redis/database layers. It works well, but distributed state ownership stays an application concern.
Queue workers and schedulers are mature, but they still need supervision, restart strategy, and failure monitoring.
Server runtime, PHP extensions, process manager setup, proxy config, certificates, and deployment orchestration.
Octane and FrankenPHP reduce request overhead, but region and capacity choices still exist at the infrastructure level.
Cloudflare primitives model
Requests run in Cloudflare's global edge runtime. There's no instance fleet to maintain for normal request handling.
Durable Objects own coordination state, KV handles hot reads, and D1/R2 handle relational/object data by access pattern.
Queues and Workflows include retries and checkpointing, so background execution is durable without process managers.
Deploys are worker-centric (wrangler deploy) with minimal host-level setup and fewer infrastructure-specific release steps.
Isolate startup is lightweight and request handling stays close to the edge location receiving traffic.
Chapter 4
When staying on Laravel is the right call.
This is not a universal "rewrite" argument. There are plenty of cases where Laravel + Octane + Laravel Cloud is exactly the right choice:
Team fluency
If your team is strong in Laravel and not set up for Workers yet, migration is mostly a people and process decision. Staying put can be the right call.
Existing PHP extensions
If your system depends on PHP-specific extensions or legacy integrations, the migration cost may not justify the benefits right now.
Mature monolith that works
If a mature Laravel app is stable and your team ships quickly, there is no reason to rewrite just to follow a trend.
Tight budget with PHP expertise
For smaller systems, Laravel hosting can be very cost-effective and straightforward. Cloud-native benefits become clearer as complexity and scale increase.
Chapter 5
What changed for me after switching.
The biggest improvement for me wasn't benchmark speed. It was mental overhead. Fewer moving pieces meant less time on maintenance and more time on product work.
wrangler deploy pushes globally in one step. I still have architectural decisions to make,
but I spend less time on host and fleet concerns.
That shift is why I now default to this model for greenfield work.
I still keep an eye on tradeoffs and edge cases, but the default path is cleaner for how I build and operate systems.
Appendix
1:1 component mapping — Laravel to cloud-native.
I keep a working matrix of Laravel/PHP components and the cloud-native primitives I use instead. If you want that detail, send me a note and I'll share the latest version.
Ready to explore