The Problem with the Original Scale to Zero
Laravel Cloud's first scale-to-zero implementation had a fundamental flaw: sleep meant complete removal. When an app went idle, it was evicted from the compute cluster entirely. The next incoming request had to trigger a full scheduling cycle—image pull, process initialization, and all. That added up to roughly 10 seconds of wake time.
For any app with real traffic, that latency was unacceptable. Compute could sleep, but databases and caches had to stay running around the clock to avoid compounding the delay further.
Checkpoint/Restore: The 20x Wake-Time Improvement
The new Flex compute on Laravel Cloud replaces cold boots with container checkpoint/restore, built on CRIU (Checkpoint/Restore In Userspace) and the zeropod runtime.
Instead of removing the app when it goes idle, the runtime writes a complete snapshot of the process state to disk on the compute node—memory pages, open file descriptors, everything. When a new HTTP request or command execution arrives, the runtime restores from that snapshot rather than booting from scratch.
The result: wake times under 500 milliseconds, a 20x improvement over the previous architecture.
"On request, the container runtime restores the app processes from the in-memory state and is able to respond to the incoming request within hundreds of milliseconds." — Cyrill Troxler, Senior Software Engineer of Infrastructure at Laravel
The Hardest Engineering Challenges
Fleet-Wide Reliability
Making checkpoint/restore work for a single app is straightforward. Making it work reliably across a large, heterogeneous fleet of apps with different runtimes and configurations is not. The team had to handle edge cases across a wide range of app setups.
OS-Level Integration on Bottlerocket
Laravel Cloud's infrastructure runs on Bottlerocket, Amazon's container-optimized Linux distribution, with SELinux enforcing strict security policies. Installing a custom container runtime on that stack required package-level integration work not supported out of the box.
The team initially considered maintaining their own Bottlerocket variant—a significant ongoing burden. They eventually found a way to install the runtime on the official upstream version, avoiding that maintenance overhead entirely.
Storage Performance vs. Cost
Sleeping apps write their in-memory state to local disk on the compute node. That storage must be fast enough to restore within hundreds of milliseconds, but cost-effective enough to operate across a global fleet. Balancing IOPS against storage size required multiple iterations.
How Compute, Database, and Cache Wake as a Unit
The three components of a Laravel Cloud stack don't rely on a central orchestrator. They signal each other through normal client connections:
- Compute wakes on an incoming HTTP connection or command execution.
- Once the app container is restored, it opens TCP connections to MySQL and Laravel Valkey using standard client drivers.
- Those TCP connections are what wake the database and cache.
This keeps coordination lightweight and eliminates an extra orchestration layer and failure point. For Valkey specifically, because the runtime restores full in-memory state, the cache is warm the moment the app reconnects—no cache-warming overhead.
Thundering Herd and Scheduled Tasks
- Concurrent requests during wake: The first request triggers the restore. Subsequent requests are queued and forwarded concurrently once the app is ready—no requests are dropped.
- Scheduled tasks: A central scheduler running outside customer workloads handles waking apps and executing
schedule:run. Your app doesn't need to be running for the scheduler to know it has work to do. - Queue workers: For immediate queue processing without a scheduled interval, managed queues run on always-warm infrastructure.
Failure Modes and Monitoring
If a checkpoint/restore wake fails, the system falls back to a cold start automatically. The request still succeeds—it just takes longer. The team monitors the custom runtime itself (not the sleeping app) and automatically restarts the runtime if health checks fail.
Key Takeaways
- Wake times dropped from ~10 seconds to under 500 ms using CRIU-based checkpoint/restore.
- The full stack (compute, database, cache) sleeps and wakes as a coordinated unit via TCP connections.
- Bottlerocket + SELinux integration required significant OS-level engineering.
- Concurrent wake requests are queued, not dropped.
- Cold-start fallback ensures no request errors on restore failure.
- Available now on Flex compute sizes: 512 MB, 1 GB, and 2 GB.
Source: How We Built Laravel Cloud's Scale to Zero — Laravel Blog, June 15, 2026
