> ## 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. # CPU and memory > Set how much compute a service gets, and see what it costs. 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 **Console** 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. **slipway.yaml** ```yaml slipway.yaml theme={"system"} version: 1 databases: - name: db engine: postgres diskSizeGB: 10 cpu: "500m" memory: 1Gi services: - name: api runtime: docker cpu: 1 memory: 2GB ports: - port: 3000 public: true - name: worker type: worker runtime: docker # no cpu or memory, so 0.5 vCPU / 512 MiB ``` `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. > [!NOTE] > > 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 | What | Rate | | - | - | | CPU | \$8.76 per vCPU per month | | Memory | \$4.38 per GiB per month | | Disk | \$0.25 per GiB per month | | Volume backups | \$0.05 per GiB per month | | Object storage | \$0.05 per GiB per month | | Egress beyond the plan allowance | \$0.01 per GB | 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](/deploys/sleep) or [paused](/deploys/pausing) 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. | | Free | Hobby | Pro | Enterprise | | - | - | - | - | - | | Price | \$0 | \$5 / month | \$20 / seat / month | Negotiated | | Included usage | \$5 one time | \$10 / month | \$20 / month, per workspace | Negotiated | | Seats | 1 | 1 | Unlimited | Unlimited | | CPU per service | 1 vCPU | 8 vCPU | 32 vCPU | Unlimited | | Memory per service | 1 GiB | 8 GiB | 32 GiB | Unlimited | | Build machine | 4 vCPU / 8 GiB | 8 vCPU / 16 GiB | 16 vCPU / 32 GiB | Unlimited | | Pods per project | 6 | 12 | 24 | Unlimited | | Running pods per org | 12 | 40 | 120 | Unlimited | | Disk size per volume | 10 GB | 50 GB | 200 GB | 500 GB | | Included egress | 100 GB | 500 GB | 2 TB | 10 TB | | Logs and metrics history | 3 days | 7 days | 30 days | 30 days | | Backup retention | Not available | 7 days | 14 days | Unlimited | | Requests per second per IP | 25 | 100 | 250 | Unlimited | | Capability | Free | Hobby | Pro | Enterprise | | - | - | - | - | - | | PR previews | Yes | Yes | Yes | Yes | | Always-on services | No | Yes | Yes | Yes | | Shell access | No | Yes | Yes | Yes | | Manual scaling and autoscaling | No | Yes | Yes | Yes | | Persistent disks | No | Yes | Yes | Yes | | Object storage | No | Yes | Yes | Yes | | Scheduled backups | No | Yes | Yes | Yes | | Access controls | No | No | Yes | Yes | | Bring your own cluster | No | No | Yes | Yes | | Forced sleep after 5 idle minutes | Yes | No | No | No | 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. | Situation | Why | | - | - | | Shrinking memory below current usage | The container would immediately exceed its own new limit, so the node declines | | No room on the node for a larger allocation | Nothing can grow in place and the pod would have to be rescheduled | | Changing whether CPU is reserved or burstable | That is fixed when the pod starts and cannot change during its life | 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. ## Related > **[Scaling](/services/scaling)** > > Run more than one copy of a service, at a fixed count or autoscaled. > **[Automatic compute](/services/automatic-compute)** > > Let slipway raise an allocation before the service outgrows it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.