Limits

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

For Teams on the Pro plan, you can pay forusage on-demand.

For members of our Pro plan, we offer an included credit that can be used across all resources and a pay-as-you-go model for additional consumption, giving you greater flexibility and control over your usage. The typical monthly usage guidelines above are still applicable, while extra usage will be automatically charged at the following rates:

See thePro 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 avercel.json configuration file, eachrewrite,redirect, orheader is counted as a Route
• If you are using theBuild Output API, you might configureroutes 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 ofdynamic routes,redirects,rewrites andcustom headers.

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

Every Build is provided with the following resources:

The limit for static file uploads in the build container is 1 GB.Pro and Enterprise customers can purchaseEnhanced or Turbo build machines with up to 30 CPUs and 60 GB memory.

For more information on troubleshooting these, seeBuild 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 is 1 GB. It is retained for one month and it applies at the level of eachBuild cache key.

Check outthe limits and pricing section for more details about the limits of theMonitoring feature on Vercel.

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

Build logs are stored indefinitely for each deployment.

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

The maximum number ofEnvironment Variables per environment perProjectis1000. For example, you cannot have more than1000 Production Environment Variables.

The total size of your Environment Variables, names and values, is limited to64KB 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 theEnvironment Variables documentation.

If you are usingSystem 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, pleasecontact our support team for assistance.

The maximum number of files that can be uploaded when creating a CLIDeployment is15,000 for source files. Deployments that contain more files than the limit will fail at thebuild 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 usingIncremental 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 orroutes with an external destination) is allowed to process an HTTP request. The maximum timeout is120 seconds (2 minutes).If the external server does not reply until the maximum timeout is reached, an error with the messageROUTER_EXTERNAL_TARGET_ERROR will be returned.

Vercel Functions do not support acting as a WebSocket server.

We recommend third-partysolutions to enable realtime communication forDeployments.

Check out theLimits and Pricing section for more details about the limits of Vercel Web Analytics.

Check out theLimits and Pricing doc for more details about the limits of the Speed Insights feature on Vercel.

Check out the Cron Jobslimits section for more information about the limits of Cron Jobs on Vercel.

The limits of Vercel functions are based on theruntime that you use.

For example, different runtimes allow for differentbundle sizes,maximum duration, andmemory.

​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 theReserved Environment Variables docs for more information.

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

Therate limits table consists of the following four columns:

• Description - A brief summary of the limit which, where relevant, will advise what type of plan it applies to.
• 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 theDuration has expired.
• 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.

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

You are able to delete up to60 domains every60 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 to20 teams every3600 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 to6 times every604800 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 build32Deployments every3600 seconds (1 hour). Should you hit the rate limit, you will need to wait another hour before you can build a deployment again.

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