The rate you pay for builds is probably not a number you chose
Vercel publishes four build machine tiers on its pricing page: Standard at $0.014 per minute, Enhanced at $0.028, Turbo at $0.105, and Elastic at $0.0035 per CPU minute. The first three are fixed. The fourth is not, and it is the one most teams are on: Vercel's own documentation states that "New Pro and Enterprise accounts use Elastic machines by default" and that "Elastic is the default for new teams". Elastic assigns between 4 and 30 vCPUs depending on what it judges your build needs, and because a CPU minute is one build minute multiplied by the number of cores used, the effective rate ranges from $0.014 per minute at 4 cores up to $0.105 per minute at 30, which is exactly the Turbo rate, arrived at without anyone ever selecting Turbo.
Where the setting actually lives
There are two places, and knowing both matters because they interact. The team-level control is in Team Settings under Build and Deployment, in the Build Machines section, and it governs what new projects inherit. The project-level control is in that same Build and Deployment section within an individual project's settings, and it overrides the team default for that project only. The common failure is auditing one and assuming the other matches: a team default set high with individual projects pinned low looks fine on every project page you check, and then bills at the higher rate the moment somebody creates project number seventeen.
Pin it to Standard and measure what you lost
Set the project to Standard, deploy, and compare the build duration against your recent history. Vercel exposes this directly in Build Diagnostics under Observability, so this is a two-minute check rather than a research project. If the build takes roughly the same time on 4 cores as it did on a larger machine, you were paying a multiple for capacity your build could not use, and you should pin every project the same way. If it genuinely slows down, you have learned something real about your build and can make an informed decision instead of an inherited one.
When a larger machine is actually the right answer
Bigger machines earn their rate on builds that are genuinely CPU-bound and parallel: heavy bundling, expensive type checking across a large codebase, or a monorepo compiling many packages at once. The test is whether your build spends its time in compilation or somewhere else. Many web builds spend the bulk of their minutes on tasks that additional cores barely accelerate, such as pre-rendering pages one after another and uploading the resulting artifacts. Measure before assuming, because this is the one item on the audit where the expensive option is sometimes correct.
The concurrency setting sitting next to it
While you are in Build and Deployment, note what Vercel documents about concurrent builds: Hobby gets 1 concurrent deployment, while Pro allows up to 500 with on-demand concurrency enabled and 3 without it, and you are billed for the build minutes you use. On-demand concurrency is a genuine convenience for a team that deploys constantly, and it is also a multiplier on build spend during a busy afternoon. It is worth a deliberate decision rather than a default.
Do this once, then check it quarterly
Build machine tier is a set-and-forget item with one failure mode: a new project inherits a team default nobody has revisited. Put a quarterly reminder against the team-level setting, and check it whenever somebody new joins with permission to create projects. Then move on to the meters that actually scale with your traffic rather than your deploy count, which is where the larger money usually is.
Reader comments
No account needed. Share what worked, what did not, and what you would add.
Add a quick note with the form below. Short, specific tips help the next reader most.