> ## 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.

# Build machine

> Choose how much CPU and memory your builds get, and what that costs.

Every project builds on a build machine you configure: a CPU and memory allocation priced
at the same unit rates as your services. A bigger machine builds faster and costs more
while it runs.

The default is 4 vCPU and 8 GiB. Most projects never change it.

## Changing it

Open the project, then **Settings → Builder**, and set CPU and memory. The change applies
to the next deploy. A build already running keeps the machine it started on.

The setting is per project rather than per service. One push builds every changed source
on the same hardware, so what you are choosing is how quickly a deploy turns around, not
how large any one image is.

Previews build on their base project's machine, so raising it speeds previews up too.

## 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.

Those are monthly figures for something running continuously. A build is charged only for
the minutes it runs, so the default 4 vCPU and 8 GiB machine works out to about \$0.10 an
hour and a three-minute build costs half a cent.

Concurrent builds each cost their own machine: a project with three changed services builds
three at once and pays for three. Time spent queued is free, because billing starts when
the build starts rather than when you push. Static site builds are free: a static site
bills nothing at runtime, and its build follows.

Builds appear on **Settings → Usage** under the service they built, labelled `builder`,
next to that service's runtime charge. They are separate lines because they run at
different sizes for different lengths of time.

## Plan limits

| | 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 |

If you ask for more than your plan allows, the sliders stop at the ceiling.

A plan change never breaks a build. If your plan's ceiling drops below what a project is
set to, the next build runs at the ceiling and records that in its timeline rather than
failing.

## When a bigger machine helps

It depends on what the build spends its time on. Compilation and bundling parallelise well,
so a monorepo with a heavy `npm run build`, a Go build across many packages, or a Rust
release build finishes measurably faster. Pulling base images, downloading dependencies and
single-threaded steps do not.

To find out for your build, time one at the default, raise the machine, and push again.
Deploy durations are on the project's Metrics page.


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