Managing Builds

When you build your application code, Vercel runs compute to install dependencies, run your build script, and sends the build output to our Compute and CDN.

By default, we enable elastic builds for paid teams. If you're on a Hobby plan and looking for faster builds, we recommend upgrading to Pro.

Visit Build Diagnostics in the Observability section in the Vercel dashboard sidebar to find your build durations. You can also use this table to quickly identify which solution fits your needs:

Hobby teams always use the Basic build machine. Basic has 2 vCPUs and 8 GB of memory.

For Pro and Enterprise customers, Elastic build machines auto-scale based on your recent build durations. New Pro and Enterprise accounts use Elastic machines by default.

You can set the build machine type in the Build and Deployment section of your settings for your team or for individual projects.

Basic is included with Hobby. For paid teams, Basic usage is billed at $0.0035 per CPU minute, or $0.007 per build minute. Elastic build machines are also billed by CPU minute, starting at $0.0035 per CPU minute. A CPU minute is one minute of build time multiplied by the number of vCPU cores used. For example, if a build takes 3 minutes and Elastic assigns the Standard machine (4 vCPUs), you're billed for 3 minutes × 4 cores = 12 CPU minutes.

Enterprise customers who have Enhanced build machines enabled via contract will always use them by default. You can view if you have this enabled in the Build Machines section of the Build and Deployment tab in your Team Settings. To update your build machine preferences, you need to contact your account manager.

On-demand concurrent builds allow your builds to skip the queue and run immediately. By default, projects have on-demand concurrent builds enabled with full concurrency. Learn more about concurrency modes.

You are charged for on-demand concurrent builds based on the number of concurrent builds required to allow the builds to proceed. See Pricing for more information.

• Hobby: 1 concurrent deployment. Builds beyond this run sequentially.
• Pro: Up to 500 concurrent deployments with on-demand concurrency (3 if on demand is off). You are billed for the build minutes you use.
• Enterprise: Custom concurrency limits tailored to your organization's needs.

When you enable on-demand build concurrency at the level of a project, any queued builds in that project will automatically be allowed to proceed. You can choose to run all builds immediately or limit to one active build per branch.

You can configure this on the project's Build and Deployment Settings page:

curl --request PATCH \
  --url https://api.vercel.com/v9/projects/YOUR_PROJECT_ID?teamId=YOUR_TEAM_ID \
  --header "Authorization: Bearer $VERCEL_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "resourceConfig": {
      "elasticConcurrencyEnabled": true,
      "buildQueue": {
        "configuration": "SKIP_NAMESPACE_QUEUE"
      }
    }
  }'

import { Vercel } from '@vercel/sdk';
 
const vercel = new Vercel({
  bearerToken: '<YOUR_BEARER_TOKEN_HERE>',
});
 
async function run() {
  const result = await vercel.projects.updateProject({
    idOrName: 'YOUR_PROJECT_ID',
    teamId: 'YOUR_TEAM_ID',
    requestBody: {
      resourceConfig: {
        elasticConcurrencyEnabled: true,
        buildQueue: {
          configuration: 'SKIP_NAMESPACE_QUEUE',
        },
      },
    },
  });
 
  console.log(result);
}
 
run();

For individual deployments, you can force build execution using the Start Building Now button. Regardless of the reason why this build was queued, it will proceed.

1. Select your project from the dashboard.

2. in the sidebar, open Deployments.

3. Find the queued deployment that you would like to build from the list. You can use the Status filter to help find it. You have 2 options:

   • Select the three dots to the right of the deployment and select Start Building Now.
   • Click on the deployment list item to go to the deployment's detail page and click Start Building Now.

4. Confirm that you would like to build this deployment in the Start Building Now dialog.

With Elastic, Vercel evaluates each project individually and assigns the build machine that best fits its actual workload. The goal is a balance between speed and price: builds that genuinely benefit from more vCPUs and memory get larger machines automatically, while builds that don't get, smaller machines so you aren't paying for compute you won't use.

In practice, this means:

• Optimized bills. Many projects don't fully utilize a Turbo machine's 30 vCPUs. Elastic detects this and assigns a smaller machine, reducing your build minute costs without making builds noticeably slower.
• Faster builds where it matters. Projects that are CPU- or memory-bound (heavy bundling, expensive type checking) are auto-upgraded to a larger machine so they finish sooner.
• No manual tuning. You don't need to benchmark each project or guess the right tier. The assignment is reevaluated as your project changes over time, so it stays right-sized as your codebase grows.

Elastic is the right choice for most projects. You may want to pin a project to a specific build machine type if:

• You want to guarantee a specific machine size on every build.
• A project has unusual resource patterns that you've already manually tuned for.

Elastic is the default for new teams.

You can enable Elastic at the team level or per project by navigating to the Build and Deployment section of your settings:

• Team settings
• Project settings

For billing information, see Pricing.

Some other considerations to take into account when optimizing your builds include:

• Understand and manage the build cache. By default, Vercel caches the dependencies of your project, based on your framework, to speed up the build process
• You may choose to Ignore the Build Step on redeployments if you know that the build step is not necessary under certain conditions
• Use the most recent version of your runtime, particularly Node.js, to take advantage of the latest performance improvements. To learn more, see Node.js

If a build has to wait for queued preview deployments to finish, it can delay the production release process. When Vercel queues builds, we'll processes them in chronological order (FIFO Order).

To ensure that changes to the production environment are prioritized over preview deployments in the queue, you can enable Prioritize Production Builds:

1. From your Vercel dashboard, select the project you wish to enable it for
2. Open Settings in the sidebar, and go to the Build and Deployment section of your Project Settings
3. Under Prioritize Production Builds, toggle the switch to Enabled