> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic compute

> Let slipway raise a service's allocation before it runs out of room.

Automatic compute raises a service's CPU and memory on the running pods when it is under
sustained pressure, and after an out-of-memory kill. It only ever grows an allocation.
Nothing shrinks automatically.

It is available on every plan, including Free, and it grows a service only within the
per-service ceiling your plan already allows.

## Turning it on

**Console**

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.

**slipway.yaml**

```yaml slipway.yaml theme={"system"}
services:
  - name: api
    runtime: docker
    cpu: "500m"
    memory: 512MB
    autoResize:
      maxCPU: 2
      maxMemory: 4GB
```

Writing the block is the opt-in. There is no `enabled: true` to remember. Use
`enabled: false` to turn it off while keeping the ceilings recorded.

`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

| Signal | Result |
| - | - |
| Memory above 85% for 3 minutes | Memory grows |
| CPU above 90% for 3 minutes | CPU grows |
| An out-of-memory kill | Memory grows immediately |

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

```yaml slipway.yaml theme={"system"}
    autoResize:
      maxMemory: 4GB
      memoryThresholdPercent: 75    # 50-99, default 85
      cpuThresholdPercent: 85       # 50-99, default 90
      sustainedSeconds: 120         # 60-3600, default 180
      stepPercent: 125              # 105-400, default 150
      cooldownSeconds: 300          # 60-86400, default 600
```

| Setting | Default | Effect |
| - | - | - |
| `memoryThresholdPercent` | 85 | How full memory gets before it counts as pressure |
| `cpuThresholdPercent` | 90 | The same for CPU |
| `sustainedSeconds` | 180 | How long pressure must hold before a step |
| `stepPercent` | 150 | How far one step moves that axis. 150 is 1.5x |
| `cooldownSeconds` | 600 | The pause after a step before another can follow |

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.

## When it does not act

| Case | Behaviour |
| - | - |
| The service autoscales on CPU | CPU is left alone and only memory grows, so adding pods and enlarging pods do not fight. The reverse applies to a memory target. |
| Sleeping or paused | Nothing is running to measure. |
| `static` or `cron` | Rejected at validation. A static site has no pod, and every cron run starts fresh at its configured allocation. |
| Previews | Previews never auto-grow, even where the spec declares it. |
| Balance at zero | Nothing grows. |
| No room on the node | The service keeps running as it was and you get a notification offering the redeploy. |

## At the ceiling

When a service reaches its ceiling and is still running hot, slipway raises one
notification with the current usage and a link to the tab, then stops. It does not repeat.

The Compute tab prices the ceiling, so you can see the most the service could cost before
you set it.

## Oversized services

With automatic compute on, slipway also watches the other direction. If a week of history
shows a service never went above 40% of what it has, you get one notification suggesting a
smaller allocation and what it would save per month.

That is advice. Nothing changes until you change it, and the notification does not repeat
for another month.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.