Skip to main content
Every service runs at a CPU and memory allocation you choose. There is no catalog of named sizes. You set two numbers and two flat unit rates price them. If you set neither, a service gets 0.5 vCPU and 512 MiB.

​
Setting an allocation

Open the service’s Compute tab and move the CPU and memory sliders. The tab quotes the allocation per second, per minute and per month before you save.The sliders stop at your plan’s per-service ceiling.
cpu accepts a number of cores (1, 0.5, 2) or a millicore string ("500m"). The minimum is 100m and the value must be a multiple of 50m. memory accepts 512MB, 1GB, 512Mi or 1Gi. The minimum is 128Mi and the value must be a multiple of 128Mi. Decimal suffixes are normalised to binary. Set one and omit the other, and the omitted one takes its default. type: static rejects both. A static site is served from the CDN and never occupies a pod.
The size: field was replaced by cpu: and memory:. A spec that still uses it fails at parse time with a message pointing here.

​
What it costs

Compute is metered by the second against the allocation a service is configured with, so a service that sleeps costs nothing while it is asleep. Disk, backups and object storage are metered on what is provisioned or held, whether or not the service is running. A service at 1 vCPU and 2 GiB costs 1 × $8.76 + 2 × $4.38 = $17.52 a month if it never sleeps. Metering is on elapsed seconds with no minimum increment, so a service alive for 90 seconds is charged for 90 seconds. A sleeping or paused service is scaled to zero and costs nothing while it is. A cron service is charged per run, for the length of the run. The rate is frozen onto the deployment when it goes out. A change to platform rates or to your configuration applies once the pod is actually running the new shape, so the charge always describes what is running.

​
Monthly minimums

The platform operator can set a minimum monthly charge per service type. The default is $0. Where one is set, a service of that type that ran at all during a billing month is charged at least the minimum, topped up at the end of the period. It applies per service, per project. Any top-up appears on Settings → Usage as “Monthly minimums”.

​
Plan ceilings

Each plan caps what a single service may be configured with. The console’s sliders stop at the ceiling and the API refuses a larger value. A deploy behaves differently. A spec asking for more than the ceiling, such as one pushed after a plan downgrade, is clamped to the ceiling and the deploy proceeds. slipway records a resources_clamped event on the deployment. A push never fails because of a billing boundary.

​
Bursting

The CPU number you configure is the limit. The scheduler reserves a fraction of it as the request, so a service can burst above its reservation when the node has headroom. Memory is always reserved at the full configured amount, because memory cannot be throttled, only OOM-killed. Managed databases are the exception on CPU: a database created from the Database page reserves its full CPU allocation and does not burst, so its latency does not depend on its neighbours.

​
Overriding an allocation per project

A project can override CPU and memory per service on its Settings → General tab. Use this when the same repository should run small in one project and large in another without branching the spec. Precedence, highest first:
  1. The project’s per-service override
  2. cpu: and memory: in slipway.yaml
  3. The default, 0.5 vCPU and 512 MiB

​
Changing a running service

A compute change is applied to the pods that are already running. There is no rebuild, no rollout, no dropped connection and no new deployment. Disk-backed services and databases resize the same way. Billing moves at the same moment. slipway records a resources_resized event on the deployment and narrates the start and finish in the service’s Logs tab.

​
When a redeploy is needed instead

Three changes cannot be applied to a live pod. In each case the service keeps running as it was and the console offers the redeploy. Editing cpu: or memory: in slipway.yaml takes effect on the next deploy, which is what the push triggers anyway.

​
If a pod is replaced

A resize applies to running pods while the workload template still holds the previous numbers until the next deploy. A pod replaced before then, by a node drain or a crash, starts on the old allocation. slipway moves it back to the current allocation within a couple of minutes, again without a restart.

Scaling

Run more than one copy of a service, at a fixed count or autoscaled.

Automatic compute

Let slipway raise an allocation before the service outgrows it.