Turning it on
- Console
- slipway.yaml
Open the service’s Compute tab and enable automatic compute under the allocation
it governs. Set a ceiling if you want one tighter than your plan’s.
maxCPU and maxMemory take the same forms as cpu: and memory:. A ceiling below the
service’s own allocation is a parse error, because the ceiling is what it may grow to.
Omitting an axis means your plan’s per-service cap bounds it, not that it stays fixed. To
let memory grow while pinning CPU, set maxCPU equal to the service’s cpu.
What triggers a step
Pressure has to be sustained across the window, so a single spike does not ratchet a
service upward. The out-of-memory case skips the window, because the container is already
dead by the time anything could be measured.
Each step multiplies the axis by 1.5, then waits ten minutes. If the service is still
short after that, it steps again, up to the ceiling. A 512 MiB service under real pressure
walks 512 → 768 → 1152 → 1792 MiB, about one step every ten minutes.
Every step is applied in place, with no restart and no redeploy, and appears on the
deployment timeline as a
resources_resized event marked automatic.
Tuning
slipway.yaml
Every setting is optional, so you can change the step size without restating the
thresholds. A value outside its range fails validation rather than being clamped.
The memory threshold is lower than the CPU threshold by default because the failure modes
differ: CPU over its limit is throttled, memory over its limit is killed.
Usage is measured every 30 seconds, so
sustainedSeconds rounds up to a multiple of 30.
A value of 90 means three observations.
Console settings override the repo for that project, and the two layer. A repo that sets
a step size and a console that sets a threshold end up with both.