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 the number of warm instances under the environment’s Settings, Compute: Warm instances on AWS (1 to 100; empty for none), or Minimum instances on GCP. With none, the environment scales to zero when idle, which suits development and staging environments where cold start latency is acceptable.

Warming up now

The environment’s overview page has a Warm instances card: enter a count and select Apply. On AWS this warms that many instances right away and saves the count, which the five-minute schedule takes on at the next deploy; 0 clears it. On GCP it sets the minimum instances. The CLI has no warmup command.

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 — idle warm instances cost nothing; you pay for the pings, one request and about a second of compute per instance every five minutes
• Cloud Run — minimum instances are billed while they run

For staging and development environments, no warm instances 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.