Cut Vercel Build Costs With Basic Machines

The cheaper build minute is not the decision. On September 3, 2026, Vercel gave Pro and Enterprise teams a new Basic option with 2 vCPUs, 8 GB of memory, and a $0.007 build-minute rate. It cuts the bill only when your cost per completed build beats Elastic after runtime, rounding, failures, and queue delay.

What Vercel changed

A build machine is the temporary computer Vercel uses to install dependencies, compile your app, and prepare a deployment. Paid projects now have a smaller fixed choice: Basic build machines are available on Pro and Enterprise, not just Hobby.

Basic has 2 vCPUs, 8 GB of memory, and 32 GB of disk. Elastic can assign 4 to 30 vCPUs and 8 to 60 GB of memory based on the project workload. New paid projects still default to Elastic.

This is a choice, not a new paid default. New paid projects still start on Elastic, and an owner can choose Basic in the team or project setting. Hobby projects keep the same included 2-vCPU machine, now named Basic.

This piece isolates the build-machine decision. The plan fee, usage credit, seats, traffic, functions, storage, and add-ons still belong in the full Vercel pricing breakdown.

The useful number is cost per completed build

Basic and Elastic start from the same CPU rate: $0.0035 per CPU minute. Their bills diverge because Basic always uses 2 vCPUs, while Elastic assigns between 4 and 30.

Vercel rounds each build's duration up to the nearest minute. That gives you two working formulas:

• Basic: rounded-up build minutes × $0.007.
• Elastic: rounded-up build minutes × assigned vCPUs × $0.0035.

At the smallest 4-vCPU Elastic assignment, the starting cost is $0.014 per billed build minute. Basic costs half as much per billed minute. Basic therefore ties when it takes exactly twice as many billed minutes and wins on price when it takes less than twice as many.

That rule changes if Elastic assigns more than 4 vCPUs. It also changes at each minute boundary because Vercel rounds the duration of every build, not the monthly total. The invoice needs your real duration and assigned machine, not a rate-card guess.

The $7 saving is real inside that example, but it may not be valuable. If every preview blocks a developer, reviewer, or coding agent, the slower feedback loop can cost more than the invoice saving. If those builds run in the background and the queue stays clear, Basic has the better unit cost.

Count failures in the numerator, too. The operating metric is total build charges divided by successful deployments. A machine that is cheap per minute but causes retries can lose on the outcome you actually buy.

Queue time is a workflow cost

Vercel's published billing formula uses build duration and CPU count. It does not add queue delay as another term. Your team still feels that delay.

When on-demand concurrency is off, Pro has 3 concurrent deployment slots. Builds beyond those active slots wait. With on-demand concurrency, Vercel lists up to 500 concurrent deployments and bills the build minutes used.

A slower Basic build holds a slot longer. That may not matter to a founder deploying a small site a few times a day. It can matter quickly when a coding agent opens several previews, an agency deploys many client projects, or a team pushes to several branches at once.

Record both clocks:

• Build duration drives the machine charge after rounding.
• Queue delay plus build duration drives time to feedback.

That is the whole decision. Optimize the first number without letting the second damage the workflow.

Who should test Basic

A solo founder with one small app

A solo SaaS founder can move a lightweight marketing site or dashboard to Basic at the project level, then compare the same representative build on Elastic. The payoff is a lower recurring build line without changing the rest of the Vercel plan.

The switch is worth keeping only if the build remains reliable and the slower run, if there is one, does not delay releases. For a project that deploys occasionally, the dollar difference may be too small to justify manual tuning.

An agency with mixed client projects

A client agency should not make one machine decision for every account. Pin small landing sites and content projects to Basic one project at a time. Leave larger storefronts, monorepos, and dependency-heavy apps on Elastic until their own measurements say otherwise.

The payoff is cleaner margin by project. One low-resource client no longer needs to inherit the same build machine as the agency's heaviest app.

An engineering lead running coding agents

Agent-driven development changes the volume side of the equation. More automated commits can mean more preview builds, so a small per-build gap repeats more often.

The engineering lead should measure a representative burst, not one quiet deployment. If Basic lowers cost per completed build but longer runs fill the 3 available slots and create a queue, the cheaper machine has moved cost from the invoice into turnaround time.

An Enterprise platform owner

Basic is available to Enterprise, but one contract detail can block a self-serve change. Enterprise customers with Enhanced machines enabled by contract use those machines by default and must contact their account manager to update machine preferences.

How to switch one project and test it

Use a project-level change first. It keeps the experiment away from unrelated apps and gives you a clean rollback path in the same setting.

1. 1

   Capture the Elastic baseline

   Open Build Diagnostics in Vercel Observability and choose a representative deployment. Record build duration, the assigned machine, billed usage, queue delay, and whether the deployment completed. Keep cache conditions and the code revision comparable for the Basic run.

2. 2

   Select Basic for the project

   Open the project in Vercel, then go to Settings, Build and Deployment, and Build Machine. Select Basic and save. Vercel documents the same choice at team level, but the project setting is the safer first test. You need the owner role to access build-machine settings.

3. 3

   Use the documented CLI path

   Vercel CLI 59.6.0 or later can make the project change with this command:

   vc project update --build-machine basic

   The easy mistake is running an older CLI and assuming the machine choice is unavailable. Check the version before treating a failed command as a plan restriction.

4. 4

   Run the same workload

   Build the same representative revision under comparable cache conditions. Record the same fields: duration, machine, billed usage, queue delay, and completion. For agent-driven work, include a normal burst so the queue has a chance to show itself.

5. 5

   Choose on outcomes

   Calculate the monthly build total and divide it by successful deployments. Keep Basic when that unit cost falls and total turnaround still meets the team's target. Return the project to Elastic in Build Machine settings when speed, memory, or reliability gets worse enough to erase the saving.

The honest limits

Basic is a smaller machine, not a more efficient version of Elastic. Its 8 GB memory ceiling is fixed. Elastic can scale as high as 60 GB and 30 vCPUs when the workload needs it.

Rounding can also eat a small saving. A few seconds past a minute boundary creates another full billed minute. Compare the billed usage shown by Vercel, not a stopwatch calculation rounded in your favor.

Elastic also keeps adapting as a project changes. Basic stays fixed. A machine choice that works for today's small app can become the wrong one after dependencies, routes, or generated assets grow.

Who should act, wait, or ignore this

• Act this week if you run a Pro or Enterprise project with stable, low-resource builds and enough build volume for a recurring per-build difference to matter.
• Wait if the project is CPU-bound, memory-heavy, close to the 45-minute limit, or already sensitive to preview queues. Establish a clean Elastic baseline first.
• Ignore the pricing change if you are on Hobby. Your included 2-vCPU machine was renamed Basic, but the machine and plan treatment did not change.
• Check the contract first if Enterprise has Enhanced machines enabled. The account manager may own the change.

The Monday move

Pick one representative small project on Monday. Run the same build on Elastic and Basic, then record duration, billed usage, assigned CPUs, queue delay, and completion. Keep the option that lowers cost per completed build without missing the team's turnaround target.

Join the newsletter for more plain-English breakdowns of the platform changes that move the budget or the workflow.