Vercel Lets You Pay for Faster Builds One Deploy at a Time

On September 17, 2026, Vercel made Turbo a one-deployment cost choice instead of a project-wide commitment. You can spend more on one urgent build, then let the next deployment return to the project's normal machine choice.

The project setting no longer has to move

A build machine is the temporary computer Vercel gives your code while it installs dependencies, compiles the app, and prepares the deployment. Turbo is the largest fixed option: 30 vCPUs, 60 GB of memory, and 64 GB of disk.

Before this change, choosing a fixed build machine meant changing a team or project setting. That made a short deadline awkward. You could pay for Turbo across routine preview builds, or change the setting for the rush and remember to change it back.

The new override attaches Turbo to one deployment. It doesn't edit the project setting. If a project normally uses Basic, Standard, or Elastic, the following deployment uses that normal selection again unless you add another override.

That's the useful part. Extra build spend can follow urgency instead of every commit.

Turbo, Enhanced, and Elastic are available on Pro and Enterprise. Hobby projects always use Basic, so this isn't a Hobby speed switch. It also does nothing useful for a project that already runs every deployment on Turbo.

Three ways to put Turbo on one deployment

The method depends on what starts the deployment. All three routes select the same one-deployment override.

1. 1

   Use the GitHub commit marker

   For a deployment triggered by Vercel's GitHub integration, put the exact, case-sensitive marker in the commit message body:

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   The marker applies only to the deployment from that commit. It currently does not work through Vercel's GitLab or Bitbucket integrations.

2. 2

   Use the Vercel CLI

   From a linked project, run:

   vc deploy --turbo

   This path requires Vercel CLI 59.20.0 or later. An older CLI is the first thing to check if the flag isn't recognized.

3. 3

   Set the deployment API field

   When an internal release service creates the deployment through POST /v13/deployments, set buildMachine to turbo in that request. The field is optional and scoped to the deployment. It does not rewrite project settings.

You need permission to update the project's build machine. There is one quiet failure mode to know: if Turbo is unavailable or your account lacks permission, Vercel uses the project's normal machine selection instead of failing the deployment.

The cost is small once and expensive by habit

Vercel currently charges build usage at $0.0035 per CPU minute. That works out to starting prices of $0.007 per billed build minute for Basic, $0.014 for Standard when it is billed, $0.028 for Enhanced, and $0.105 for Turbo.

The billing clock rounds each build up to the nearest minute before multiplying by the machine's CPU count. A Turbo build that runs for 3 minutes 40 seconds is therefore billed as 4 minutes, or $0.42.

For the project-level Basic versus Elastic decision, read Cut Vercel Build Costs With Basic Machines. The new decision here is narrower: whether one deadline is worth the Turbo premium.

Workload example, not a benchmark

Assume a team ships 20 routine deployments and 1 urgent deployment in a week. Its own measurements show the same workload taking 7 minutes 20 seconds on Basic and 3 minutes 40 seconds on Turbo. Those timings are made up for the arithmetic. Turbo will not cut every build in half.

The one urgent override adds $0.364 compared with running that deployment on Basic. In this example, that premium buys an observed 3 minutes 40 seconds on the release that matters.

Keeping the 20 routine builds on Basic makes the weekly total $7.28 lower than running all 21 on Turbo. That's the new budget control in one line. The real decision needs your own durations because cache state, CPU use, memory pressure, and rounding can all move the result.

Who gets a useful workflow from this

A solo founder shipping a production fix

A founder with a GitHub-connected SaaS can put the marker on one hotfix commit. The payoff isn't a permanently faster project. It's a shorter wait on the release tied to an outage, customer promise, or launch window, followed by normal spending on the next push.

An agency release lead with one deadline

An agency can use vc deploy --turbo for the client release that has people waiting for review. Routine previews stay on the project's usual configuration, which keeps the build line from quietly expanding across every client revision.

A platform engineer with an approval path

A platform team can add buildMachine: "turbo" only to an approved urgent-release path in its deployment service. That turns extra compute into an explicit release decision that can be logged, reviewed, and costed instead of a standing project default.

The honest limits

Thirty vCPUs does not mean a build will run 15 times faster than Basic's 2 vCPUs. Some builds cannot keep all those cores busy. Vercel says many projects do not fully use a Turbo machine, which is also why Elastic can choose a smaller machine for routine work.

Turbo also changes the machine, not the queue policy. If the delay is mostly waiting for a build slot, a larger machine may solve the wrong problem. Compare time spent queued with time spent building before paying for more CPU.

Cache state can ruin a comparison too. A warm default build and a cold Turbo build do not tell you what the machine changed. Use similar revisions and cache conditions, and compare billed minutes as well as wall-clock time.

Run one controlled trial

1. 1

   Record the normal deployment

   Open Build Diagnostics and capture the project's normal machine selection, build duration, queue time, billed minutes, and result. Pick a deployment that resembles the urgent workload you care about.

2. 2

   Override one deployment

   Use the GitHub marker, CLI flag, or API field on one comparable deployment. Do not change the team or project build-machine setting.

3. 3

   Price the observed saving

   Multiply the rounded-up Turbo build minutes by $0.105. Compare that charge with the normal deployment's billed usage, then divide the extra dollars by the minutes actually saved.

4. 4

   Check the following deployment

   Trigger one more normal deployment without the marker, flag, or API field. Confirm that it uses the project's usual machine selection. This catches a mistaken project-setting change and proves the override stayed temporary.

What to do now

• Act this week if you run a Pro or Enterprise project with occasional deadline-driven releases and a normal machine setting you want to keep.
• Measure first if the project uses Elastic. It may already assign enough CPU and memory, so forcing Turbo can raise the bill without moving the clock much.
• Use a project setting instead if most deployments need Turbo. Repeating an exception on every commit is a policy disguised as a flag.
• Ignore this if you are on Hobby, already default to Turbo, or your delay comes mainly from the queue.

The Monday move

Pick one representative deployment on Monday. Record the normal build, run one Turbo override, calculate the premium against the time actually saved, then send a normal deployment and confirm the project returned to its usual configuration.

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