Vapor, Laravel's own
Per-invocation billing on Lambda was a real strength for spiky, quiet workloads. Vapor is closed to new sign-ups and fully supported for existing customers.
LaravelCloud
Private Cloud
A thesis story
Idle should cost
what idle uses.
On Laravel Cloud, Flex compute sleeps when no request arrives and stops billing for compute while it sleeps. On the new Flex sizes it wakes in under 500 milliseconds, by restoring a snapshot of the running app rather than booting it. The database and cache can sleep with it.
See what idle costs
The idea in one line Sleep is a snapshot, not a shutdown.
One Flex environment, asleepThen one request arrives
Cold boot · the original designabout 10 s
Restore · new Flex sizesunder 500 ms
0 s2.557.510 s
App · wakes on HTTP or a commandRestored
MySQL Flex · wakes on the first TCP connectionFew hundred ms
Valkey · memory restored with itWarm
Scheduler · runs outside your appAlways on
While asleep: no compute charge; database storage stays online
0 replicas · asleep
The commercial reading
Most environments
are idle most hours.
Staging, previews, internal tools, client demos and side projects spend far more time waiting than working. On most hosts they bill the whole time. The question for a buyer is simple: what are we paying for between requests?
Before June 2026Compute slept. The rest kept billing.
A ten-second wake was too slow to stack a database and cache on top, so most apps kept them running around the clock.
Since June 2026, MySQL from JulyThe stack sleeps as a unit
Compute, database and cache sleep and wake together, so an idle environment stops paying for all three kinds of compute.
Preview environmentsSuperscript's reason to move
Previews were expensive to keep running on Heroku. Letting idle ones sleep was one of two features that decided it.
The other half of idleScaling back down
Filament's server had been sized for a launch spike and could not scale back down. Replicas that shrink after the peak are the same idea, short of zero.
The bill follows use, the database included.
MySQL Flex databases can scale to zero since 20 July 2026, with an idle window from one minute to one hour, or never. Prices vary by region; see the Cloud pricing page rather than a figure here.
Sources: Monitor 563 (Laravel blog, "How we built Laravel Cloud's scale to zero", 15 June 2026), 472 (Cloud changelog, 20 July 2026), 556 (Laracon US 2026 roundup, 29 July 2026), 998 (Superscript), 997 (Filament); laravel.com/cloud/docs/compute.
The technical reading
One request,
asleep to answered.
Five moments, in order. None of them needs a change to your application: it opens a database connection as it always does, and the database wakes because of it.
Going to sleep
When no inbound request reaches the app within the sleep timeout, the runtime writes a checkpoint of the process state, memory pages and open file descriptors included, to disk on the compute node. Only a small custom runtime keeps running.
- Technique
- Container checkpoint and restore, from CRIU
- Applies to
- Flex compute only; the sub-500 ms wake on new Flex sizes only (512 MB, 1 GB, 2 GB)
- Legacy Flex
- Previous wake behaviour, typically 5 to 20 seconds
- To switch on
- Scale to Zero toggle on the App cluster, then redeploy
The first request
The request reaches the proxy, and the runtime restores the app from its snapshot instead of scheduling a workload, pulling an image and booting PHP. If more requests arrive meanwhile, they queue and are forwarded together once the app is ready. None is dropped.
- Skipped
- Scheduling, image pull, process start: the old ten seconds
- Wakes on
- An inbound HTTP request, or a command execution
- Your code
- Unchanged
Database and cache
There is no central orchestrator. The restored app opens normal MySQL and Valkey client connections, and those TCP connections wake the database and cache. A proxy in front of each MySQL cluster holds the connection while compute resumes.
- MySQL Flex
- Storage stays mounted; the first query takes a few hundred ms longer
- Valkey
- In-memory state restored, so the cache comes back warm
- Idle window
- MySQL: one minute to one hour, or never
Work while asleep
A central scheduler outside your workload wakes a Laravel app to run schedule:run, so nothing falls behind. Once woken, the app stays awake for the sleep timeout. A queued job still running when that timeout elapses can be interrupted.
- Scheduled tasks
- Wake the app automatically; keep them inside the sleep timeout
- Self-run workers
- A manual wake interval wakes the app on a fixed schedule
- Queued jobs
- The docs recommend managed queues: Flex workers scale to zero, jobs up to 90 seconds; Pro workers stay on with no fixed limit
- Worker clusters
- Stay awake, or sleep alongside the App cluster
If the wake fails
If a restore fails, the platform starts the container from scratch. That request waits longer, but it does not return an error. Because a sleeping app has nothing to check, Cloud monitors the custom runtime itself and restarts it if it stops answering.
- Fallback
- A cold start, slower, with no error to the user
- Monitored
- The runtime's reachability, against a threshold
- Hardest part
- Reliability across a large fleet with many runtimes, on Bottlerocket with SELinux
Field marks. Inbound traffic on port 8080 resets the sleep timer. A Symfony app's scheduled tasks should run on an always-awake worker cluster. Managed queues set
QUEUE_CONNECTION=cloud; Horizon and queue:failed, queue:retry, queue:clear do not support them.Sources: Monitor 563 (the engineering post, read in full), 472, 556; laravel.com/cloud/docs/compute and laravel.com/cloud/docs/queues, read 8 October 2026.
Two Laravel answers
Idle, the Laravel way.
A whole stack waking.
Laravel
Laravel Cloud, Flex
The app sleeps as a snapshot of a booted process. Database and cache follow it down. Awake, it can run Octane, workers and a scheduler like any server.
When to leave it off
Steady production traffic gains little from sleeping, and Pro compute does not scale to zero. Jobs that must start at once belong on managed queues.
Sources: Monitor 563 (20x, about 10 s to under 500 ms), 227 (Vapor sign-ups closed, 23 September 2026); the Vapor and Cloud sheets; laravel.com/cloud/docs/compute.
The lesson, with its source
The platform wakes.
The database decides.
A Laravel Solutions Engineer pointed k6 at a Cloud app with autoscaling on. He works at Laravel and says so; this is not an independent benchmark. He also published the result that went badly.
The platform alone
17,935requests a second at peak, through the full middleware stack- 39.6 million requests, 173 HTTP failures
- About 50 replicas at the ramp, then 10 to 20
The database added
46%error rate at about 4,000 requests a second- Every error a database timeout or connection failure
- Cloud held 50 replicas, with no restarts
Pooling configured
No figurepublished; the author reports the database kept up once tuned- Connection pooling and PgBouncer settings adjusted
- His note: not a database vendor problem, a configuration one
Managed queues too
< 1 sidle queue workers waking, down from about 30 seconds- Announced at Laracon US 2026
- Workers scale to zero when the queue empties
“Tune your database before you blame your platform.”Laravel blog, k6 load test, 25 March 2026 · Monitor 588
Asleep is a state.
Not an outage.
Three questions for any team: which of your environments sees no traffic most hours; which scheduled or queued work assumes the app is always up; and has your database been tuned for the connections a quickly scaling app will open.