A container app scales between a minimum and a maximum number of instances. When traffic stops, instances above the minimum go to sleep after an idle timeout and stop costing money; the next request wakes one. This page covers the settings that control that for container apps. Static, hybrid and Worker SSR apps run on the edge network and have nothing to scale or sleep.
Note
Available on every plan, where container apps are available.
Where the settings live
| Setting | Where |
|---|---|
| Max instances | Overview → App card. Saves as you change it; applies on the next deploy. |
| Sleeps after | Overview → App card, or Sleep, scaling, region. |
| Min instances (always awake) | Overview → App card, right under Max instances, or Sleep, scaling, region. |
| Scaling windows | Overview → App card → Sleep, scaling, region. |
| Run jobs on their own instance, Keep the jobs instance awake, Worker mode | Overview → App card → Sleep, scaling, region, under Behaviour. |
Everything saves as you change it and applies on the next deploy. (These used to be on a separate Container page; its old link now opens Overview.)
How instances fill up
Each request goes to the first instance with room. When every running instance is at capacity, the next request starts another, up to your maximum. When the maximum is reached, requests are spread at random across the running instances.
An instance's capacity depends on the stack and size:
| Size | PHP requests at once (php-fpm) | Octane (Swoole, RoadRunner) | Node or Ruby requests at once |
|---|---|---|---|
| 1/16 vCPU | 1 | — | 50 |
| 0.25 vCPU, 1 GB | 12 | 8 | 50 |
| 0.5 vCPU, 4 GB | 16 | 16 | 50 |
| 1 vCPU, 3 GB | 32 | 30 | 50 |
| 2 vCPU, 6 GB | 64 | 62 | 50 |
| 4 vCPU, 12 GB | 128 | 126 | 50 |
A PHP instance runs one request per PHP worker process. The number of workers comes from memory: what is left after 192 MB for nginx, the PHP master and opcache, divided by 56 MB per php-fpm worker (96 MB per Octane worker, which keeps the app booted), at most 32 per vCPU (at least 12) and 128 in all. A request can still use up to 128 MB; if the instance runs out of memory, the next deploy moves it up a size. Inertia SSR takes two workers' memory. A custom size follows the same rule. Open WebSockets count as in-flight requests for as long as they are open.
Keep a visitor on the same instance (in Sleep, scaling, region, on by default) sets a dply_instance cookie so a visitor's session and sockets stay on one container. Turn it off to spread every request at random.
Sleep
An instance that has had no request for the Sleeps after time goes to sleep and is not billed while asleep. Choose 5m, 10m, 30m, 1h, 6h or 24h. New apps default to 5m.
While the app is awake, the App card on Overview counts down to sleep (Sleeps in 7:32 without a request), resetting on each request. It also shows how long the app has been awake and when it last got a request. When the app is asleep the card says Asleep; with Min instances above zero it says Always awake.
A longer timeout means fewer cold starts and more billed time. The Cost estimate on the App card shows what your size costs at a given number of hours awake each day, and how much sleeping saves.
Keep instances awake
Set Min instances (always awake) on the App card, under Max instances, to keep that many instances running at all times (0 to your maximum). Instances below the minimum never sleep, so those visitors never hit a cold start. 0 scales to zero when idle. dply checks every minute and starts any instance below the minimum, including one the platform restarted.
The Cost estimate on the App card shows what always-awake instances cost.
Scaling windows
Scaling windows set a different minimum and maximum for certain times, such as business hours or a launch. In Overview → App card → Sleep, scaling, region, select Add a window, then set:
- Days:
Daily,Weekdays,Weekends, a single weekday, or One date. - From and Until: a window starts and ends on the same day. For an overnight window, add two.
- Time zone: any IANA time zone, such as
America/New_York. - Always awake and Instances: 0–20 and 1–20.
When windows overlap, a single date wins over a weekday, which wins over weekdays or weekends, which win over daily. Outside every window the Always awake count and the app's Instances apply. A deploy reserves capacity for the largest maximum any window can ask for.
What keeps an app awake
An instance stays awake, and billed, while any of these is true:
- It has received a request within the sleep timeout.
- It holds an open WebSocket. The socket counts as activity on every message, so one idle browser tab keeps the instance awake.
- It is below Min instances, in the current scaling window or by default.
- It is the jobs instance with Keep the jobs instance awake on.
These wake an app and then let it sleep again after the timeout:
- A queue batch from a Queues resource. With Run queued jobs and scheduled tasks on their own instance on, the batch goes to a separate jobs instance (one extra instance on the bill while it runs) instead of a web instance.
- The Laravel scheduler, but only when one of your scheduled tasks is due. See Scheduled tasks.
- A scheduled task from Overview.
dply's own uptime checks do not keep an app awake. While the app is asleep a check does not wake it and reads Asleep; while it is awake a check is not counted as a request, so the app still reaches its sleep timeout. (Apps last deployed before this change skip the check when its previous check was the last request.)
Queue workers run as their own always-on instances and do not keep the web instances awake.
When an app is paused
If your organization has no plan, or reaches its spending cap, container traffic stops. Visitors get HTTP 503 with Retry-After: 3600 and the text "This app is paused." WebSockets already open stay open until they close; new ones are refused. Scheduled tasks do not run, and queue batches are held and retried an hour later. Traffic resumes when you choose a plan or raise the cap. See Paused accounts.