Skip to main content
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

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

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.