
September 08, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
Serverless PHP options in 2026 compared matter because traffic spikes and idle servers both cost money. Traditional VPS hosting with PHP-FPM still runs most production Laravel and WordPress sites I maintain. Yet event-driven APIs, webhooks, and bursty workloads can fit function-as-a-service or container-based serverless better. This guide compares the platforms that actually run PHP 8.3–8.5 in 2026, with real trade-offs on cold starts, database connections, and deployment workflows. If you are weighing Ubuntu server setup for PHP apps against pay-per-invocation billing, start here.
What counts as serverless PHP in 2026?
True serverless PHP means your code runs on a platform that scales to zero and bills per request or per CPU-second. You do not patch the OS or reload PHP-FPM yourself. In practice, PHP serverless always ships as a custom runtime or container because PHP was not a first-class FaaS language like Node.js or Python.
The four serious options in 2026 are:
- AWS Lambda + Bref — PHP layers and custom runtimes for Lambda.
- Laravel Vapor — managed Laravel deployment on top of Lambda, SQS, and RDS.
- Google Cloud Run — Docker containers with automatic scaling, ideal for Symfony or Laravel Octane.
- Azure Container Apps — similar container model with KEDA-based scaling.
Azure Functions and Google Cloud Functions offer limited or experimental PHP support. Most teams skip them and use containers instead. Platforms like Vercel and Netlify are not realistic PHP homes in 2026.
For background on the non-serverless baseline, see the Nginx vs Apache comparison for PHP sites. Most Laravel booking platforms I ship still run on VPS with queues and scheduled tasks.
How does AWS Lambda with Bref run PHP?
Bref packages PHP for AWS Lambda using custom runtimes and layers. You deploy a serverless.yml file via the Serverless Framework or SAM. Composer dependencies get bundled into the deployment artifact. PHP 8.3 and 8.4 runtimes are supported; verify 8.5 support in the Bref release notes before upgrading.
Minimal Bref handler example
# serverless.yml (excerpt)
service: my-api
provider:
name: aws
runtime: provided.al2
region: ap-south-1
plugins:
- ./vendor/bref/bref
functions:
api:
handler: public/index.php
layers:
- ${bref:layer.php-83}
- ${bref:layer.php-83-fpm}
events:
- httpApi: '*'
The handler bootstraps your front controller. Laravel and Symfony both work, but boot time directly affects cold-start latency. Keep service providers lean. Use OPcache tuning guidance as a mental model—even on Lambda, opcache is pre-warmed inside the runtime layer.
What Bref handles well
- API endpoints and webhook receivers (payment callbacks, SMS delivery reports).
- Scheduled tasks via EventBridge instead of server cron.
- Queue workers as separate Lambda functions consuming SQS messages.
- Asset storage on S3 with CloudFront—no local filesystem.
Where Bref struggles
Cold starts on Lambda typically run 200 ms to 2 s for PHP, depending on memory and package size. A heavy Laravel 13 app with dozens of service providers pays a real penalty. Lambda max execution time is 15 minutes, but API Gateway times out at 29 seconds for HTTP APIs. Long exports belong on a queue worker function or Cloud Run instead.
Database connections are the other pain point. MySQL on RDS does not love hundreds of short-lived Lambda invocations opening fresh connections. Use RDS Proxy, or Aurora Serverless v2 with connection pooling. For Redis 8.10 caching, place ElastiCache in the same VPC and attach Lambda to private subnets.
Is Laravel Vapor worth the cost in 2026?
Laravel Vapor is the managed layer on top of Bref and AWS. It handles deployments, environment management, databases, queues, and scheduling for Laravel 12 and 13 applications. If your stack is already Laravel, Vapor removes most serverless wiring.
Vapor pricing has two parts: the Vapor subscription (roughly USD 39–399/month depending on team size) plus AWS usage. A low-traffic API might cost USD 5–20/month in AWS fees. A busy app with RDS, SQS, and CloudFront can exceed USD 200/month quickly. Budget Rs 15,000–30,000/month (~USD 110–220) as a starting envelope for a production Laravel API in Nepal-region AWS.
Vapor deployment workflow
- Install
laravel/vapor-cliandlaravel/vapor-corevia Composer 2.10. - Run
vapor loginandvapor initin your Laravel project root. - Configure
vapor.ymlwith memory, timeout, database, and queue settings. - Deploy with
vapor deploy production—assets upload to S3, functions update atomically. - Point your domain via Vapor's DNS or CloudFront distribution.
# vapor.yml (excerpt)
id: 12345
name: booking-api
environments:
production:
memory: 1024
cli-memory: 512
runtime: php-8.3
build:
- 'composer install --no-dev'
- 'php artisan event:cache'
deploy:
- 'php artisan migrate --force'
Vapor shines for teams that want Laravel conventions without managing Lambda config files. I've seen it work well for webhook-heavy integrations similar to an eSewa payment integration where the main site stays on VPS but payment callbacks run serverless.
It is a poor fit when you need WebSockets, long-running CLI scripts, or heavy session-based admin panels. Vapor pushes you toward S3 storage, database sessions, and queue-driven architecture. That matches modern Laravel patterns, but migrating a legacy monolith hurts.
How does Google Cloud Run compare for PHP containers?
Cloud Run runs Docker containers that scale to zero and bill per request plus vCPU-seconds. You build a standard PHP-FPM + Nginx image—or use Laravel Octane with RoadRunner or Swoole for faster boot. This path feels closest to traditional hosting while keeping automatic scaling.
See the RoadRunner gRPC guide for how Octane-style runtimes reduce per-request bootstrap cost. On Cloud Run, a slim Octane container often beats Lambda cold starts for Symfony 8.1 or Laravel 13 APIs.
Sample Cloud Run Dockerfile
FROM php:8.4-cli
RUN apt-get update && apt-get install -y libzip-dev \
&& docker-php-ext-install pdo_mysql zip opcache
COPY --from=composer:2.10 /usr/bin/composer /usr/bin/composer
WORKDIR /app
COPY . .
RUN composer install --no-dev --optimize-autoloader
CMD ["php", "artisan", "octane:start", "--server=roadrunner", "--host=0.0.0.0", "--port=8080"]
Deploy with gcloud run deploy. Set min instances to 1 if cold starts matter for user-facing APIs. Cloud Run allows up to 60-minute request timeouts on configured services—far beyond Lambda's API Gateway limit.
Cloud Run fits Symfony 8.1 apps that need PHP 8.4.1 minimum and long request windows. Multi-tenant SaaS with per-tenant scaling also maps well. Review Laravel multi-tenancy approaches before splitting tenants across Cloud Run services.
What about Azure and hybrid serverless patterns?
Azure Functions does not offer maintained PHP runtimes in 2026. Azure Container Apps is the practical choice: deploy the same Docker image you would use on Cloud Run, connect to Azure Database for MySQL or PostgreSQL 18, and scale with KEDA triggers including HTTP, queues, and cron.
Hybrid patterns often win on real client projects. Keep the main Laravel app on a VPS managed through Linux system administration. Offload image processing, PDF generation, or webhook ingestion to Lambda or Cloud Run. This mirrors how legal-tech portals handle document uploads on the primary server but process conversions asynchronously.
For CI/CD, serverless does not remove the pipeline. You still lint, test, and deploy artifacts. The DevOps roadmap for 2026 applies—only the target changes from SSH plus Deployer 7 to vapor deploy or gcloud run deploy.
Which serverless PHP platform should you pick?
Use a decision matrix grounded in traffic shape, framework, and ops capacity. No single platform wins every workload.
| Criteria | AWS Lambda + Bref | Laravel Vapor | Google Cloud Run | Azure Container Apps | VPS + PHP-FPM |
|---|---|---|---|---|---|
| Best for | Webhooks, cron, queue workers | Laravel-only teams | Containerised APIs, Symfony | Azure ecosystem shops | Steady traffic, admin UIs, WordPress |
| Cold start | 200 ms–2 s typical | Same (uses Lambda) | 500 ms–3 s (mitigate with min instances) | Similar to Cloud Run | None (always warm) |
| Max HTTP timeout | 29 s (API Gateway) | 29 s default | Up to 60 min | Configurable, long requests OK | Unlimited (set in Nginx) |
| PHP versions | 8.2–8.4 via layers | 8.2–8.3 managed | Any (your Dockerfile) | Any (your Dockerfile) | 8.3/8.4/8.5 side-by-side |
| Database fit | Needs RDS Proxy / Aurora | Managed RDS via Vapor | Cloud SQL, connection pooling | Azure DB flexible server | Direct MySQL 9.7 / MariaDB 12.3 |
| Ops burden | High (YAML, IAM, VPC) | Low for Laravel | Medium (Docker + GCP) | Medium (Docker + Azure) | High but familiar |
| Cost at low traffic | Very low (free tier) | Sub + AWS fees | Low with scale-to-zero | Low with scale-to-zero | Fixed Rs 1,500–5,000/mo (~USD 11–37) |
| Laravel 13 fit | Good with tuning | Excellent | Excellent with Octane | Good | Excellent (default) |
WordPress 7.1 and WooCommerce 11.1 remain poor serverless candidates. Persistent filesystem expectations, plugin compatibility, and page-cache plugins assume a local disk or shared storage. Keep WordPress on VPS or managed WordPress hosting via WordPress development services.
Cost reality check
Serverless is not automatically cheaper. A Rs 3,000/month (~USD 22) VPS comfortably runs a Laravel 12 app with MySQL, Redis, and cron. The same app on Vapor plus RDS can cost 3–5× more at moderate traffic. Serverless wins when traffic is sparse or spiky—internal admin tools used twice a day, or payment webhooks that fire unpredictably.
Use the JSON formatter to inspect Lambda CloudWatch log payloads during debugging. Structured logging matters more when you cannot SSH into a box.
How do you migrate PHP to serverless without breaking production?
Incremental migration beats a big-bang rewrite. A pattern I've used on production Laravel applications:
- Audit state — list filesystem writes, session driver, cache driver, and cron entries.
- Externalise storage — move
storage/and uploads to S3-compatible object storage. - Switch sessions and cache — database or Redis sessions; never file-based sessions on Lambda.
- Extract one route — deploy a single webhook endpoint serverless while the main app stays on VPS.
- Move queues — replace
databasequeue driver with SQS or Redis-backed workers. - Cut over DNS — point API subdomain to API Gateway or Cloud Run after load testing.
Watch for packages that assume long-lived processes. PHP Fibers help concurrent I/O inside a single invocation, but they do not replace a persistent worker for heavy background jobs. For API design during split deployments, follow consistent API versioning strategies.
Database choice still matters. MariaDB vs MySQL comparisons apply whether the database sits on VPS or Aurora. Serverless functions benefit from managed databases with autoscaling storage.
For new Laravel projects, read why developers should learn Laravel in 2026 before committing to Vapor. Framework fluency reduces migration risk either way.
Key Takeaways
- Serverless PHP in 2026 means Lambda + Bref, Laravel Vapor, or container platforms— not native PHP on every cloud function service.
- Pick Lambda or Vapor for Laravel webhooks, queues, and cron; pick Cloud Run when requests exceed 29 seconds or need custom PHP 8.5 images.
- Keep WordPress, WooCommerce, and session-heavy admin panels on VPS—the hosting model still fits better.
- Plan for cold starts, RDS Proxy, and S3 storage before migrating; file-based sessions and local disks break on Lambda.
- Hybrid architectures often deliver the best ROI: VPS monolith plus serverless workers for spikes and integrations.
- Compare total cost—including RDS, SQS, and Vapor subscription—not just per-invocation Lambda pricing.
People Also Ask
Can PHP run on AWS Lambda in 2026?
Yes. Bref provides maintained PHP runtimes for AWS Lambda, supporting PHP 8.2 through 8.4 via layers. You package your application with Composer, deploy through Serverless Framework or Laravel Vapor, and connect to RDS through RDS Proxy for connection pooling.
Is Laravel Vapor the only way to run Laravel serverless?
No. You can deploy Laravel on Cloud Run or Azure Container Apps using Docker and Octane. Vapor is the lowest-friction path for AWS Lambda specifically. It manages infrastructure, SSL, and queue workers through Laravel-native commands.
Why is serverless PHP slower on cold starts?
Each Lambda invocation may boot a fresh PHP process, load Composer autoloaders, and initialise Laravel service providers. Container platforms face similar boot costs unless min instances stay warm. OPcache and slim service providers reduce the penalty.
When should you avoid serverless for PHP entirely?
Avoid serverless when your app needs local filesystem writes, long-lived WebSockets, heavy admin sessions, or predictable 24/7 traffic on a budget. A Rs 3,000/month VPS with PHP-FPM 8.4 often outperforms and undercuts a fully managed serverless stack.
Pick the right PHP hosting model for your traffic
Serverless PHP options in 2026 compared boil down to traffic shape and framework—not hype. Lambda and Vapor excel at event-driven Laravel workloads. Cloud Run suits containerised APIs with longer timeouts. Most business-critical sites I maintain still run on VPS with Deployer 7, and that remains the sane default for 2026.
Before you re-architect, profile your traffic and list filesystem dependencies. If you want help choosing between serverless and traditional hosting for a Laravel or API project, API development and web development services cover architecture through deployment. You can also review shipped work on the portfolio or contact us to discuss your stack.
Frequently Asked Questions
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.

