Deploying Laravel on AWS Lambda with Vapor

By Kokil Thapa | Last reviewed: August 2026

Deploying Laravel on AWS Lambda with Vapor transforms a traditional monolithic application into an auto-scaling serverless system, eliminating server management while introducing new constraints around execution time, filesystem access, and cold starts. For teams evaluating this architecture in 2026, the decision rarely comes down to technology alone; it hinges on traffic patterns, budget predictability, and operational tolerance. If you are considering this path, understanding the real-world trade-offs is more valuable than reading marketing copy. This guide covers the practical realities of serverless Laravel architectures based on production experience.

How does deploying Laravel on AWS Lambda with Vapor actually work?

Vapor is not a hosting provider in the traditional sense; it is a deployment tool that provisions and configures native AWS services on your behalf. When you run a deployment, Vapor creates or updates an API Gateway, Lambda functions, S3 buckets for assets, CloudFront distributions, and RDS or Aurora Serverless databases depending on your configuration. Your Laravel application code is packaged into a ZIP artifact, uploaded to S3, and invoked by Lambda through a custom runtime layer optimized for PHP 8.4.

The critical distinction from traditional hosting is the execution model. On a VPS or EC2 instance, PHP-FPM maintains persistent worker processes that handle requests sequentially within a long-lived environment. On Lambda, each request may trigger a fresh container initialization. This means global state does not persist between requests, the filesystem is ephemeral except for /tmp, and any dependency on local disk writes (like session files or log files) must be refactored to use external stores like Redis or S3.

This architecture demands discipline. Applications that write logs to storage/logs, store uploads locally, or rely on cron jobs running on the same server will fail silently or break outright. You must configure Laravel’s logging driver to CloudWatch, set the session and cache drivers to Redis or DynamoDB, and offload file storage to S3. These are not optional optimizations; they are prerequisites for correctness.

What are the real costs of running Laravel on AWS Lambda?

Cost is the most misunderstood aspect of serverless Laravel. Marketing materials emphasize "pay only for what you use," which is technically true but practically misleading for applications with sustained traffic. Lambda pricing includes per-request charges ($0.20 per million requests), GB-second compute charges, and API Gateway fees ($1.00 per million requests for REST APIs). For a moderate-traffic application receiving 5 million requests monthly with average 256MB memory allocation and 200ms execution time, expect monthly costs between $80–$150 USD (approximately NPR 10,500–19,500) before database expenses.

Database costs often dwarf compute costs. Aurora Serverless v2 scales automatically but has a minimum capacity of 0.5 ACUs (~$45/month even at idle). For low-traffic projects common in Nepal's legal-tech or SME sector, a provisioned Aurora instance or even an external managed MySQL service may be more economical. Always model your specific workload before committing; a simple cost estimation exercise prevents budget surprises.

Cold starts add indirect cost through user experience degradation. Without provisioned concurrency, Lambda initializes a new container in 300–800ms for PHP runtimes. Provisioned concurrency eliminates this but adds fixed hourly charges. For client-facing applications where perceived performance matters, factor this into both UX decisions and budget. Internal tools or APIs with tolerant clients can often skip provisioned concurrency entirely.

How do you configure and deploy a Laravel project with Vapor?

The deployment workflow assumes familiarity with AWS IAM, Composer, and the Laravel ecosystem. Ensure your local environment runs PHP 8.2 or higher (8.4 recommended for latest Vapor runtime support) and Node.js 22 LTS for asset compilation.

1. Install the Vapor CLI globally: Run composer global require laravel/vapor-cli. Verify installation with vapor --version.
2. Authenticate with AWS: Configure AWS credentials locally via aws configure or environment variables. Create an IAM user with AdministratorAccess initially; restrict permissions later using Vapor’s documented minimal policy.
3. Initialize Vapor in your project: Run vapor init inside your Laravel root. This generates vapor.yml with staging and production environments. Commit this file to version control.
4. Configure environment variables: Never hardcode secrets. Use vapor env:pull staging to download, edit locally, then vapor env:push staging to upload. Variables like APP_KEY, DB_HOST, and REDIS_HOST are injected at runtime.
5. Adapt filesystem and queue configuration: Set FILESYSTEM_DISK=s3, SESSION_DRIVER=redis, CACHE_STORE=redis, and QUEUE_CONNECTION=sqs in your Vapor environment. Local disk writes will fail.
6. Build frontend assets: Run npm ci && npm run build locally. Vapor uploads compiled assets to S3 and serves them via CloudFront. The Lambda function itself should not run Node.js.
7. Deploy: Execute vapor deploy staging. Monitor progress in the terminal; first deployments take 5–10 minutes as infrastructure provisions. Subsequent deploys are faster.

# Example vapor.yml snippet for production
id: 48291
name: my-laravel-app
environments:
    production:
        memory: 1024
        cli-memory: 512
        runtime: php-8.4
        build:
            - 'COMPOSER_MIRROR_PATH_REPOS=1 composer install --no-dev'
            - 'php artisan optimize'
        deploy:
            - 'php artisan migrate --force'
        cache-warmup: true
        warm: 5  # Provisioned concurrency units

Post-deployment verification is non-negotiable. Hit health-check endpoints, verify database connectivity, test file uploads to S3, and confirm queue workers process jobs. CloudWatch Logs (accessible via vapor tail production) are your primary debugging interface; there is no SSH access to inspect containers.

When should you avoid serverless Laravel for production?

Serverless is not universally superior. Three scenarios consistently favor traditional infrastructure over Lambda:

• Sustained high-throughput workloads: If your application handles >10M requests/month with predictable load, reserved EC2 instances or managed platforms like Laravel Forge on DigitalOcean typically cost 40–60% less than equivalent Lambda spend. The auto-scaling premium isn’t justified when utilization is consistently high.
• Long-running background processing: Lambda enforces a 15-minute maximum execution timeout. Video transcoding, large PDF generation, or complex ETL jobs exceeding this limit require architectural workarounds (chunking, step functions) or dedicated queue workers on EC2. Refactoring working code solely to fit Lambda constraints often introduces more risk than value.
• Tight regulatory or compliance boundaries: Some Nepal government or financial sector contracts mandate data residency within specific jurisdictions or on-premises infrastructure. While AWS has regions in Asia-Pacific, verifying compliance for sensitive legal or medical data requires due diligence that may negate serverless simplicity benefits. Always confirm requirements before architecting.

Additionally, teams without AWS operational experience face a steep learning curve. Debugging distributed systems across Lambda, API Gateway, SQS, and CloudWatch requires different skills than troubleshooting a monolithic LAMP stack. If your team’s strength lies in PHP development rather than cloud infrastructure, investing in experienced Laravel developers who understand both paradigms prevents costly misconfigurations.

How do you optimize cold starts and performance in Vapor?

Cold starts are the most cited drawback of serverless PHP. Mitigation strategies depend on your tolerance for latency versus cost:

1. Enable provisioned concurrency for critical paths: In vapor.yml, set warm: N under your environment. Each unit keeps one container initialized and ready. Start with 3–5 units for user-facing routes; monitor CloudWatch InitDuration metrics to adjust. This adds ~$15–30/month per unit but guarantees sub-100ms responses.
2. Minimize deployment package size: Exclude dev dependencies (--no-dev), prune unused vendor files, and avoid bundling unnecessary binaries. Smaller packages reduce S3 download time during initialization. Use Vapor’s build array to automate cleanup.
3. Optimize bootstrap time: Cache configuration (php artisan config:cache), routes (route:cache), and views (view:cache) during build. Avoid service providers that perform I/O during boot. Profile bootstrap with vapor tail to identify slow initializations.
4. Use ARM64 (Graviton2) runtime: Specify runtime: php-8.4-arm in vapor.yml. ARM-based Lambda offers ~20% better price-performance for PHP workloads and often faster cold starts due to lighter runtime overhead.

For applications where occasional 500ms latency is acceptable (admin panels, internal tools), skip provisioned concurrency entirely. Reserve it for customer-facing checkout flows, authentication endpoints, or API routes where P95 latency directly impacts conversion or satisfaction. Measure before optimizing; many teams over-provision based on fear rather than data.

Making the Right Choice for Your Laravel Deployment

Deploying Laravel on AWS Lambda with Vapor solves real problems—automatic scaling, reduced operational overhead, and alignment of cost with actual usage—but introduces equally real constraints around filesystem immutability, execution timeouts, and variable billing. The right choice depends on your specific traffic profile, team expertise, and budget tolerance rather than technological novelty. For bursty workloads, greenfield APIs, or projects where server management distracts from core product development, Vapor delivers genuine value. For steady high-volume sites, long-running processes, or teams deeply comfortable with traditional infrastructure, a well-configured VPS remains simpler and cheaper.

Evaluate honestly: if your primary motivation is avoiding server administration rather than matching architectural strengths to workload characteristics, consider managed platforms like Laravel Forge first. If you’ve validated that serverless fits your needs, start with a non-critical environment to build operational muscle before migrating production traffic. When you’re ready to discuss whether Vapor makes sense for your specific project, reach out for a technical consultation grounded in real deployment experience rather than theoretical benchmarks.