Warmup

Serverless functions (Lambda, Cloud Run) scale to zero when idle. The first request after a cold start incurs additional latency while the container initializes. Warmup keeps a configurable number of instances warm to avoid this.

How warmup works

AWS Lambda

The adapter handles warmup by self-invoking. When a warmer event fires:

1. The primary Lambda invocation fans out N concurrent self-invocations (where N is your desired warm count)
2. Each invocation sends a GET request to the warmup path (e.g., /up)
3. The adapter recognizes warmer events and returns 200 immediately without forwarding to your application for the coordination invocations

This keeps N container instances initialized and ready to serve real requests.

GCP Cloud Run

Cloud Run supports minimum instances natively. SKE configures the min-instances setting on your Cloud Run service to keep the specified number of containers warm.

Configuring warmup

Set concurrency in ske.yml:

name: my-app
environments:
  production:
    concurrency: 10    # Keep 10 instances warm
  staging:
    concurrency: 0     # Scale to zero (default)

A concurrency of 0 means no warmup — the environment scales to zero when idle. This is appropriate for development and staging environments where cold start latency is acceptable.

Triggering warmup manually

ske warmup --env production

✓ Warmup triggered (10 instances)

This sends an immediate warmup event. In normal operation, warmup runs automatically on a schedule.

Warmup path

The adapter sends warmup requests to the path configured by SKE_WARMUP_PATH. For Laravel, this defaults to /up (Laravel’s health check route). The warmup request is a lightweight GET that exercises the container initialization (autoloader, service container boot) without heavy application logic.

Cost considerations

Warm instances consume resources:

• Lambda — you pay for provisioned concurrency while instances are warm, even without traffic
• Cloud Run — minimum instances are billed at a reduced idle rate

For staging and development environments, concurrency: 0 avoids these costs entirely. Reserve warmup for production environments where cold start latency matters.

Cold start anatomy

A typical Laravel cold start involves:

1. Container image pull (~1–3s, cached after first pull)
2. PHP-FPM startup (~200ms)
3. Composer autoloader initialization (~100–300ms)
4. Laravel service container boot (~200–500ms)
5. First request handling

Total cold start: typically 2–5 seconds. Warmup eliminates this for the configured number of concurrent requests.