Engineering - 9 min read
Serverless PHP actually works now
By Hana Nguyen - 28 April 2026 - 1 views
Photo: Christopher Gower on Unsplash
A field report from three months of running a real Laravel app on a serverless platform. The good parts, the gotchas and the surprisingly small operational footprint.
The first time I ran Laravel on a serverless platform I did not enjoy it. Cold starts were rough, the cache layer was a stranger, and the scheduler did not exist.
The second time was different. The platform had matured, the tooling had grown a few opinions, and I had learned which corners to round off. Three months in, the boring bits are boring, which is the highest compliment you can pay a hosting platform.
Cold starts are fine. The trick is to pre-build everything that can be pre-built: route cache, view cache, config cache, autoloader optimisation. All of that happens in the build step. By the time your first request lands, PHP has very little thinking to do.
The database is the part that surprised me most. Connections are pooled, retries are sensible, and I have not yet seen the kind of "too many connections" failure that haunted my early containerised deployments.
The scheduler is the bit that needs the most thought. Serverless platforms typically do not run system cron. The pattern that works is to expose a token-protected endpoint inside your app that triggers Laravel's scheduler, and then hit it once a minute from somewhere that does run cron. A small EC2 box, a GitHub Actions workflow on a cron trigger, or a managed scheduled task on the same cloud will all do the job.
Migrations are easy if you remember that release scripts run after deploy but before traffic shifts. Put your migrate command there, fail the deploy if it fails, and you get atomic releases for free.
I would not pick serverless for everything. Big background jobs are still happier on a long-lived box. But for a content site with a busy front page and a quiet long tail, the operational footprint is hard to beat.
The second time was different. The platform had matured, the tooling had grown a few opinions, and I had learned which corners to round off. Three months in, the boring bits are boring, which is the highest compliment you can pay a hosting platform.
Cold starts are fine. The trick is to pre-build everything that can be pre-built: route cache, view cache, config cache, autoloader optimisation. All of that happens in the build step. By the time your first request lands, PHP has very little thinking to do.
The database is the part that surprised me most. Connections are pooled, retries are sensible, and I have not yet seen the kind of "too many connections" failure that haunted my early containerised deployments.
The scheduler is the bit that needs the most thought. Serverless platforms typically do not run system cron. The pattern that works is to expose a token-protected endpoint inside your app that triggers Laravel's scheduler, and then hit it once a minute from somewhere that does run cron. A small EC2 box, a GitHub Actions workflow on a cron trigger, or a managed scheduled task on the same cloud will all do the job.
Migrations are easy if you remember that release scripts run after deploy but before traffic shifts. Put your migrate command there, fail the deploy if it fails, and you get atomic releases for free.
I would not pick serverless for everything. Big background jobs are still happier on a long-lived box. But for a content site with a busy front page and a quiet long tail, the operational footprint is hard to beat.
