Limits

You can raise many of the limits on this page. The process depends on your plan:

• Enterprise: Contact your Vercel account team to request a limit increase. Limits marked as Custom are set in your contract.
• Pro: Talk to sales about Enterprise for custom limits.
• Hobby: Upgrade to Pro for higher limits.

To prevent abuse of our platform, we apply the following limits to all accounts.

Hobby teams get a monthly allotment of each billable resource. Pro teams get a monthly credit that applies across billable resources, and Vercel charges for additional usage on demand once you use that credit. For the allotments and the on-demand rates, see typical monthly usage guidelines.

See the Pro trial limitations section for information on the limits that apply to Pro trials.

The limit of "Routes created per Deployment" encapsulates several options that can be configured on Vercel:

• If you are using a vercel.json configuration file, each rewrite, redirect, or header is counted as a Route
• If you are using the Build Output API, you might configure routes for your deployments

Note that most frameworks will create Routes automatically for you. For example, Next.js will create a set of Routes corresponding to your use of dynamic routes, redirects, rewrites and custom headers.

The maximum duration of the Build Step is 45 minutes. When the limit is reached, the Build Step will be interrupted and the Deployment will fail.

Every build container has a fixed amount of resources available to it. You can find the resources available for each build machine type here.

For more information on troubleshooting these, see Build container resources.

When using the CLI to deploy, the maximum size of the source files that can be uploaded is limited to 100 MB for Hobby and 1 GB for Pro. If the size of the source files exceeds this limit, the deployment will fail.

The maximum size of the Build's cache depends on the build machine type:

Elastic build machines use the limit of the machine type assigned to each build.

The cache is retained for one month and applies at the level of each Build cache key.

See the Observability Plus limitations section for the limits that apply to Observability Plus, which includes Observability Query.

Monitoring is deprecated and replaced by Observability Plus. If your team still has access to Monitoring, see Monitoring limits and pricing.

There are two types of logs: build logs and runtime logs. Both have different behaviors when storing logs.

Build logs are stored indefinitely for each deployment.

Runtime logs are stored for 1 hour on Hobby, 1 day on Pro, and for 3 days on Enterprise accounts. To learn more about these log limits, read here.

The maximum number of Environment Variables per environment per Project is 1000. For example, you cannot have more than 1000 Production Environment Variables.

The total size of your Environment Variables, names and values, is limited to 64KB for projects using Node.js, Python, Ruby, Go, Java, and .NET runtimes. This limit is the total allowed for each deployment, and is also the maximum size of any single Environment Variable. For more information, see the Environment Variables documentation.

If you are using System Environment Variables, the framework-specific ones (i.e. those prefixed by the framework name) are exposed only during the Build Step, but not at runtime. However, the non-framework-specific ones are exposed at runtime. Only the Environment Variables that are exposed at runtime are counted towards the size limit.

• To prevent abuse, Vercel implements soft limits of 100,000 domains per project for the Pro plan and 1,000,000 domains for the Enterprise plan. These limits are flexible and can be increased upon request. If you need more domains, please contact our support team for assistance.

The maximum number of files that can be uploaded when creating a CLI Deployment is 15,000 for source files. Deployments that contain more files than the limit will fail at the build step.

Although there is no upper limit for output files created during a build, you can expect longer build times as a result of having many thousands of output files (100,000 or more, for example). If the build time exceeds 45 minutes then the build will fail.

We recommend using Incremental Static Regeneration (ISR) to help reduce build time. Using ISR will allow you pre-render a subset of the total number of pages at build time, giving you faster builds and the ability to generate pages on-demand.

The amount of time (in seconds) that a proxied request (rewrites or routes with an external destination) is allowed to process an HTTP request. The maximum timeout is 120 seconds (2 minutes). If the external server does not reply until the maximum timeout is reached, an error with the message ROUTER_EXTERNAL_TARGET_ERROR will be returned.

See the Limits and Pricing section for more details about the limits of Vercel Web Analytics.

See the Limits and Pricing doc for more details about the limits of the Speed Insights feature on Vercel.

See the Cron Jobs limits section for more information about the limits of Cron Jobs on Vercel.

Vercel Workflows limits the size and throughput of each workflow run, including events and steps per run, payload size, stored data per run, and stream throughput. It also rate limits the requests your team's workflows make to the Workflows backend, such as creating events, writing to streams, and reading run data. Requests over the rate limit are retried automatically with backoff, so hitting it slows your workflows down but does not cause them to fail. See Workflow limits and Workflow rate limits for the values on each plan.

Vercel Functions run on Fluid compute, which is enabled by default for new projects. Its key limits per plan:

For the full reference, see Vercel Functions limitations.

​Vercel does not support connecting a project on your Hobby team to Git repositories owned by Git organizations. You can either switch to an existing Team or create a new one.

The same limitation applies in the Project creation flow when importing an existing Git repository or when cloning a Vercel template to a new Git repository as part of your Git organization.

See the Reserved Environment Variables docs for more information.

Rate limits are hard limits that apply to the platform when performing actions that require a response from our API.

The rate limits table consists of the following five columns:

• Description - A brief summary of the limit which, where relevant, will advise what type of plan it applies to.
• Name - The unique identifier of the limit. Some limits share a description, so use the name to tell them apart.
• Limit - The amount of actions permitted within the amount of time (Duration) specified.
• Duration - The amount of time (seconds) in which you can perform the specified amount of actions. Once a rate limit is hit, it will be reset after the Duration has expired. If a description mentions a different time period, the Duration column shows the window the API enforces.
• Scope - How the rate limit is applied:
  • owner - Rate limit applies to the team or to an individual user, depending on the resource.
  • user - Rate limit applies to an individual user.
  • team - Rate limit applies to the team.
  • project - Rate limit applies to an individual project.

Below are six examples that provide further information on how rate limits work.

You are able to delete up to 60 domains every 60 seconds (1 minute). Should you hit the rate limit, you will need to wait another minute before you can delete another domain.

You are able to delete up to 20 teams every 3600 seconds (1 hour). Should you hit the rate limit, you will need to wait another hour before you can delete another team.

You are able to change your username up to 6 times every 604800 seconds (1 week). Should you hit the rate limit, you will need to wait another week before you can change your username again.

You are able to build 100 Deployments every 3600 seconds (1 hour). Should you hit the rate limit, you will need to wait another hour before you can build a deployment again. This corresponds to the api-deployments-free-per-hour limit in the table below.

You are able to deploy 100 times every 86400 seconds (1 day). Should you hit the rate limit, you will need to wait another day before you can deploy again.

You can trigger deploy hooks up to 60 times every 3600 seconds (1 hour) per project, across all deploy hooks in the project. This corresponds to the "Deploy hook triggers per hour" limit in the table below.

The following table lists all API rate limits that apply when using the Vercel REST API. These limits apply to actions such as deployments, domain management, team operations, and more.

Dynamic quotas cap how fast your provisioning rate for a resource can grow. They do not cap the total number of actions in a fixed window.

Each dynamic quota has an allowed rate, measured per minute, that moves between a minimum and a maximum. The unit depends on the resource and is named in the limit's description.

• You start at the minimum rate when you have made no requests against the limit for 10 minutes.
• While you consume at or above your current allowed rate, that rate climbs at the ramp per minute rate, toward the maximum rate.
• Consuming less than your allowed rate lets it decay back down toward the minimum at the same slope.

Your allowance is one minute's worth of your current allowed rate, so you can spend a full minute of capacity in one burst and then wait for it to refill.

For example, take a limit with a minimum rate of 100 units per minute, a ramp of 200 units per minute, and a maximum rate of 1,000 units per minute. After 10 minutes with no requests you start at 100 units per minute, which gives you an allowance of 100 units. Keep consuming at or above your allowed rate and it climbs to 300 units per minute after one minute, 500 after two minutes, and reaches the 1,000 maximum after four and a half minutes of sustained usage. Drop below your allowed rate and it falls back toward 100 units per minute at the same slope.

Once your recent usage has drawn down your allowance, the API responds with a 429 status code and a rate_limit_exceeded error. The error message tells you how to react: while you are below the maximum, it reports the rate you are ramping up to, which means a retry will succeed shortly. Continuing the example above, a request rejected while your allowed rate is 300 units per minute returns a message like:

Allocation rate limit exceeded (300 units/min). Allocation rate is ramping up to 500 units/min, retry shortly.

A single request can be larger than your full allowance. When your allowance is full, that request still goes through, but it drains your allowance below zero. Later requests get a 429 until your allowance refills. Continuing the example above, a 250-unit request admitted when your allowance is 100 units leaves you 150 units short, so follow-up requests are rejected for a short time.

The dynamic quotas table consists of the following five columns:

• Description - A brief summary of the limit which, where relevant, will advise what type of plan it applies to.
• Minimum rate (per minute) - The rate you start at, and the floor your allowed rate decays back to. The API returns this as minRate.
• Maximum rate (per minute) - The highest rate the limit can ramp up to. The API returns this as maxRate.
• Ramp (per minute) - How much the allowed rate climbs for each minute of sustained usage, toward the maximum. The API returns this as stepPerMinute.
• Scope - How the rate limit is applied:
  • owner - Rate limit applies to the team or to an individual user, depending on the resource.
  • user - Rate limit applies to an individual user.
  • team - Rate limit applies to the team.
  • project - Rate limit applies to an individual project.