How to Improve Laravel Vapor Response Times with Prewarming

Prewarming in Laravel Vapor reduces cold starts, which is critical for serverless applications. When you deploy, no Lambda containers are warm and ready to handle requests by default. This leads to guaranteed cold starts that can add up to 2 seconds to response times. Prewarming sends requests to a specified number of containers on deployment and continues pinging every 5 minutes to keep them warm.

How Much Prewarming Do You Need?

Consider a $5/month DigitalOcean droplet with 1GB of memory. If each Laravel request uses approximately 25MB, the droplet can theoretically handle about 40 concurrent requests (assuming all memory is allocated to PHP).

To match that concurrency in Vapor, you would need 40 warm Lambda containers. The good news: this is not expensive.

Cost Comparison

AWS Lambda pricing in US East (N. Virginia):

• Duration cost: $0.0000166667 per GB-second
• Request cost: $0.20 per million requests

For a Lambda function with 1024MB memory:

• A prewarm ping runs roughly every 5 minutes
• 40 containers x 12 pings/hour x 24 hours = 11,520 requests per day
• Monthly: ~345,600 requests
• Request cost: approximately $0.07/month
• Duration cost (assuming 100ms per ping): approximately $0.06/month

Total prewarming cost for 40 containers: approximately $0.13/month -- dramatically cheaper than even the most basic VPS.

Configuring Prewarming in Vapor

In your vapor.yml configuration, set the warm value for each environment:

environments:
  production:
    warm: 40

This tells Vapor to maintain 40 warm containers at all times.

When to Increase Prewarming

Monitor your application's concurrency patterns. If you notice cold starts during peak traffic periods, increase the warm count. Common triggers include:

• Marketing campaigns that drive sudden traffic spikes
• Email blasts that send many users to your site simultaneously
• Time-zone-based traffic patterns where peak hours require more capacity

Prewarming vs. Provisioned Concurrency

AWS also offers Provisioned Concurrency as an alternative to prewarming. This keeps Lambda functions initialized and ready to respond in double-digit milliseconds. However, Provisioned Concurrency is significantly more expensive than the Vapor prewarming approach and is typically only necessary for latency-critical applications where even occasional cold starts are unacceptable.

Best Practices

1. Always prewarm production environments. There is no good reason to skip prewarming given the negligible cost.
2. Set warm values based on typical concurrent usage, not peak traffic. Auto-scaling handles burst traffic; prewarming handles baseline load.
3. Monitor cold start rates through CloudWatch metrics to fine-tune your warm count over time.
4. Consider separate deployments for different workloads (web requests vs. queue workers) with independent prewarming configurations.

Prewarming is one of the simplest, cheapest optimizations you can make for a serverless Laravel application. For pennies per month, you eliminate the most common complaint about serverless architectures: cold start latency.